IPv4 vs IPv6

IPv4 vs IPv6 Introduction to IPv6 Microsoft is delivering support for the emerging update to the Internet Layer Protocol through Internet Protocol version 6 (or simply IPv6 (RFC 2460)) for packet-switched internetworks. IPv4 is currently the dominant Internet Protocol version, and was the first to receive widespread use. The Internet Engineering Task Force (IETF) has designated IPv6 as the successor to version 4 for general use on the Internet. It significantly increases the size of the address space used to identify communication endpoints in the Internet, thereby allowing it to continue its tremendous growth rate. IPv6 is also known as IPng (IP Next Generation). Limitations of IPv4 Most of today's internet uses IPv4, which is now nearly twenty years old. IPv4 was remarkably but in spite of that it is beginning to have problems. Most importantly, there is a growing shortage of IPv4 addresses, which are needed by all new machines added to the Internet. The limited address range forces organizations to use Network Address Translation (NAT) firewalls to map multiple private addresses to a single public IP address. NATs does not support standards-based network-layer security and also creates complicated barriers to VoIP, and other services. The routing tables of Internet backbone routers are becoming larger. A separate routing table entry is needed for each network resulting in a large number of routing table entries. Security was also an issue for IPv4. Although there are lots of ways of encrypting IPv4 traffic, such as using the IPSec protocol, but unfortunately all of the IPv4 encryption methods are proprietary and no real standard encryption methods exist.

IPv6 Features Features of IPv6 The IPv6 header has a new header format that is designed to minimize header overhead. This optimization is achieved by moving both non-essential fields and optional fields to extension headers that appear after the IPv6 header. Intermediate routes can process the streamlined IPv6 header more efficiently. IPv4 headers and IPv6 headers do not interoperate. IPv6 is not a superset of functionality, that is backward compatible with IPv4 is not possible. A host or router must use an implementation of both IPv4 and IPv6 to recognize and process both header formats. The IPv6 header is only twice as large as the IPv4 header, even though IPv6 addresses are four times as large as IPv4 addresses. IPv6 features a larger address space than that of IPv4. IPv6 has 128-bit (16 byte) source and destination IP addresses. Although 128 bits can express over 3.4×1038 possible

combination's, the large address space of IPv6 has been designed for multiple levels of subnetting and address allocation from the Internet backbone to the individual subnets within an organization. Multicast, the ability to send a single packet to multiple destinations, is part of the base specification in IPv6. This is unlike IPv4, where it is optional (but usually implemented). Multicasting is delivering a data stream to multiple destinations at the same time, with no duplication unless called for. Those functionalities are not supported by IPv4. The other two types of addressing that are standard practice for IPv6 are unicast and anycast. The former is a transmission from just one host to just one other host; the latter is from one host to the nearest of many hosts. The Time-to-Live field of IPv4 has been replaced by a Hop-Limit field. IPv6 offers a higher level of built-in security, and it has been specifically designed with mobile devices in mind. The mobility comes in the form of Mobile IP, which allows roaming between different networks without losing an established IP address. Unlike mobile IPv4, Mobile IPv6 (MIPv6) avoids triangular routing and is therefore as efficient as normal IPv6. IPv6 can easily be extended by adding extension headers after the IPv6 header. Unlike options in the IPv4 header, which can support only 40 bytes of options, the size of IPv6 extension headers is constrained only by the size of the IPv6 packet. Jumbograms: IPv4 limits packets to 64 KB of payload. IPv6 has optional support for packets over this limit, referred to as jumbograms, which can be as large as 4 GB. The use of jumbograms may improve performance over high-MTU networks. The presence of jumbograms is indicated by the Jumbo Payload Option header. IPv6 also includes standardized support for QoS. The QoS implementation is set up so that routers can identify packets belonging to an individual QoS flow. Furthermore, QoS instructions are included in the IPv6 packet header. This means that the packet body can be encrypted, but QoS will still function because the header portion containing the QoS instructions is not encrypted. This will make it possible to send streaming audio and video over the Internet with IPSec encryption, but in a manner that guarantees adequate bandwidth for real-time playback.

Difference Between IPv4 and IPv6 IPv4       

Source and destination addresses are 32 bits (4 bytes) in length. IPSec support is optional. IPv4 header does not identify packet flow for QoS handling by routers. Both routers and the sending host fragment packets. Header includes a checksum. Header includes options. Address Resolution Protocol (ARP) uses broadcast ARP Request frames to resolve an

      

IP address to a link-layer address. Internet Group Management Protocol (IGMP) manages membership in local subnet groups. ICMP Router Discovery is used to determine the IPv4 address of the best default gateway, and it is optional. Broadcast addresses are used to send traffic to all nodes on a subnet. Must be configured either manually or through DHCP. Uses host address (A) resource records in Domain Name System (DNS) to map host names to IPv4 addresses. Uses pointer (PTR) resource records in the IN-ADDR.ARPA DNS domain to map IPv4 addresses to host names. Must support a 576-byte packet size (possibly fragmented).

IPv6              

Source and destination addresses are 128 bits (16 bytes) in length. IPSec support is required. IPv6 header contains Flow Label field, which identifies packet flow for QoS handling by router. Only the sending host fragments packets; routers do not. Header does not include a checksum. All optional data is moved to IPv6 extension headers. Multicast Neighbor Solicitation messages resolve IP addresses to link-layer addresses. Multicast Listener Discovery (MLD) messages manage membership in local subnet groups. ICMPv6 Router Solicitation and Router Advertisement messages are used to determine the IP address of the best default gateway, and they are required. IPv6 uses a link-local scope all-nodes multicast address. Does not require manual configuration or DHCP. Uses host address (AAAA) resource records in DNS to map host names to IPv6 addresses. Uses pointer (PTR) resource records in the IP6.ARPA DNS domain to map IPv6 addresses to host names. Must support a 1280-byte packet size (without fragmentation).

IPv6 Header

IPv6 header contains the following things:  

Version - This field contains the version of the IP used in the packet. It is of 4-bit in IP version 6. Traffic class - This is an 8-bits field determining the packet priority. Priority values

     

subdivide into ranges: traffic where the source provides congestion control and noncongestion control traffic. Flow label - This 20 bits specifies the QoS management. Originally created for giving real-time applications special service, but currently unused. Payload length - This 16 bits determines the payload length in bytes. When cleared to zero, the option is a "Jumbo payload" (hop-by-hop). Next header - This 8-bits field specifies the next encapsulated protocol. The values are compatible with those specified for the IPv4 protocol field. Hop limit - This is an 8-bits field newly introduced in IPv6. It replaces the time to live field of IPv4. Source Address - This 128 bits field determines the logical address of the host that is sending the packet. Destination Address - This 128 bits field determines the logical address of the host that is receiving the packet.

The payload can have a size of up to 64KB in standard mode, or larger with a "jumbo payload" option. The IPv6 Headers In Chapter 24 you learned about the simple IPv4 header format. Headers are used by protocols to provide information about source and destination addresses, protocols, or the payload encapsulated by the datagram. It is typical that one protocol's packet is sent as the payload of another protocol. For example, the IP datagram is usually sent across most LANs encapsulated in an Ethernet frame. At the destination, the Ethernet portion of the frame is stripped off and the IP packet information is revealed. The IP information is then removed by the protocol stack, and the TCP (or other protocol) information is then removed before the actual data is reassembled and sent to an application. A few of the IPv4 fields were never put to any practical use. And some of those fields no longer exist in the IPv6 header. In Figure 35.1 you can see the fields that make up the IPv6 header. The fields for IPv6, as shown in Figure 35.1, are as listed here: 







Version This 4-bit field is the version of the Internet Protocol. The value for IPv4 was 4. The version for IPv6 in this field is 6. Routers and other devices use this value to determine what type of datagram is being processed. Traffic Class Similar to the Flow Label field, this field enables nodes to specify a particular "traffic class," the definition of which is still being defined by many RFC documents. This field should be supported by any intervening device (such as a router) that understands this field (as it exists today), and ignored by those that do not. Flow Label This 20-bit field is used to request that devices that stand between the source and the destination give special preference to this datagram. This can be compared to the Quality of Service field of IPv4 headers. Payload Length This 16-bit field is used to indicate the length of the payload section of the datagram. This does not include the original header of the IP datagram, but it does include any additional headers, as well as the actual payload of the datagram.





 

Next Header One of the most useful features that IPv6 provides is that additional headers can be included in a datagram, in addition to the main IPv6 header itself. There are many types of headers (discussed later in this chapter), and they can be useful depending on the type of payload, or the treatment of the current datagram (such as routing techniques). Hop Limit This 8-bit field is similar to a Time to Live (TTL) field used by many other protocols. It is decremented by 1 at each router the datagram passes through. When the value reaches 0, the datagram can be discarded. Source Address A 128-bit address used to describe the IP source of the datagram. Destination Address A 128-bit address used to describe the IP destination address of the datagram.

This section describes just the initial IPv6 header format. In the next section you will learn about how IPv6 can include additional headers that extend the traditional header to provide information about additional services for the IP protocol. IPv6 Extension Headers In general, most protocols have header information followed by a payload that contains the actual data to be transmitted from one point to another. Some protocols include a trailer that usually is used to provide some type of integrity check, such as CRC, to ensure that the frame or datagram has arrived at the destination without corruption. Still other protocols, and we're talking about IPv6 here, allow for additional headers to follow the initial IPv6 header, to describe certain aspects of the datagram. These headers are not required, but one or more can be placed into the datagram. These additional extension headers are placed directly after the IPv6 header, where the payload section is usually located. The payload that follows the IPv6 header, or the extension headers, will be a header for the encapsulated upper-layer protocol being transported by the IPv6 datagram. It is interesting to note that among the following headers, if the hop-by-hop header is used, it must follow the IPv6 header as the first additional header. Other extension headers don't have to be in any particular order, but the RFCs do suggest that certain headers be placed in a certain order. Note Although the extension headers don't necessarily have to be placed in any particular order (except for the hop-by-hop header, described in the following text), any node that needs to look at the extension headers is required to do so in the order in which they appear in the datagram. A node cannot simply look through the headers trying to find a specific header.

The field Next Header is used to indicate whether another header follows the current header, after the initial IPv6 header. Yet if the next header is not one that the receiving node recognizes, the node should discard the datagram and send an ICMP message to the source

indicating that there was a problem with the packet. In IPv6, the ICMP code for this is 1, which in text format means "unrecognized Next Header Field Header type encountered." This ICMP message is used in many of the IPv6 procedures. It is important to note that an IPv6 datagram doesn't have to have any extension headers. They are used only when the feature is implemented in the IPv6 hardware (or software) routing mechanism. The extension headers that can follow the IPv6 header include these: 







Hop-by-Hop If present, this is the only header that must be examined by every node (read that as router, whether an actual router device or a computer acting as a router). This header, as described previously, must be placed directly after the IPv6 header. If you look back at the Next Header field of the IPv6 header shown in Figure 35.1, a value of zero indicates that the Hop-by-Hop header is the next header, and must be examined. The IPv6 header is the only header that can use a value of zero in the Next Header field. If any other extension header contains this value, an ICMP message value of 1 will be sent back to the source. This value indicates "unrecognized Next Header type encountered." This option type can be of variable length. Destination Options This header can also be of variable length, and is used only by the destination of the packet. This extension header is used to carry additional information, which is to be defined by other RFCs. Routing This field specifies specific network nodes that a packet should be passed through (a route) to reach its destination. Routers usually decide the route a packet will take depending on the routing protocol. Using this option, IPv6 routers can specify a route. The nodes listed in this option are not guaranteed, however, because there is always the possibility that a particular node might not be online. Or the Maximum Transmission Unit (MTU) of a router listed here might not accept the size of the packet, and thus the packet can't be sent through that router. Fragment This option enables the source node to fragment a packet so that it will be able to reach its destination based on the MTU of the routers between the source and the destination. However, because this value is set by the source node, and it cannot be certain of the MTU value of intervening nodes, packets can still be dropped. A field called the M flag field can be set to one if more fragments of the original message are to be sent, or zero if the packet contains the last fragment of the original message. An Identification field is used to identify which fragmented packets should be considered as a group to be reassembled at the destination node. At the destination, fragments are identified by the source address + destination address + Identification field. Note IPv6 assumes a minimum MTU of 1,280 bytes. If the MTU of any link (router) that lies between the source and the destination of the packet uses a smaller MTU, then the packet will be fragmented by the router that lies between the source and the destination, not by IPv6 itself.

  

Authentication This extension header is described in detail in Chapter 46, "Virtual Private Networks (VPNs) and Tunneling." Encapsulating Security Payload This extension header is described in detail in Chapter 46. Upper-layer header This header follows the other headers, as in an IPv4 packet, and describes the data contained in the remainder of the payload section of the packet.

The preceding list is described in the recommended order suggested by the RFC. This can change depending on a few circumstances. For example, if the Destination Options header should be read not just by the node specified by the destination address found in the initial IPv6 header, but also by the other destinations listed in the Routing header, then the Destination Options header should be placed immediately after the Hop-by-Hop header, followed by the Routing header. The Options Type Field for Hop-by-Hop and Destination Options If the Destination Options header should be examined only by the final destination node, it should be placed just before the upper-layer header. The Options Type field for Hop-by-Hop and Destination Options is an 8-bit field. However, it should be interpreted by bit values, not by byte values. Table 35.1 lists the first two highest-order options type bits. These bits specify what should be done if a node does not understand the option. Table 35.1. High-Order 2-Bit Option Type Values Value Action 00

Ignore this header and continue to process the remaining headers, if any.

01

Drop this packet.

10

Drop this packet and send the source address an ICMP packet indicating that option type was not recognized for this packet, and indicating the header that was not recognized.

11

Similar to 10, but not applicable for multicast packets.

The third-highest-ordered bit used is either zero or one. If the bit has a value of zero, the data contained in the option cannot be changed by a node it passes through on the way to its eventual destination. If the bit has a value of one, a node can change data in the extension header. The Next Header field is used by all options. It simply specifies what the next option (following the current option) will be. These option type numbers are based on those described for IPv4. These numbers were originally defined in RFC 1700, and later RFCs. However, the RFC process was not sufficient to keep up with newer protocols and services that were being developed, so an online database now exists at the Web site www.iana.org. You can use this database to determine what type of protocol or option the Next Header field indicates.