6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM ,XGMSKTZULLYKZ HOZY This field indicates where in the original datagram this fragment belongs. The fragment offset is measured in units of 8 bytes (64 bits). The first fragment has offset zero. In other words, the transmitted offset value is equal to the actual offset divided by eight. This constraint necessitates fragmentation in such a way that the offset is always exactly divisible by eight. The 13-bit offset also limits the maximum sized datagram that can be fragmented to 64 kb. :OSKZURO\K HOZY The purpose of this field is to cause undeliverable datagrams to be discarded. Every router that processes a datagram must decrease the TTL by one and if this field contains the value zero, then the datagram must be destroyed. The original design called for TTL to be decremented not only for the time it passed a datagram, but also for each second the datagram is held up at a router (hence the ‘time’ to live). Currently all routers simply decrement it every time they pass a datagram. 6XUZUIUR HOZY This field indicates the next (higher) level protocol used in the data portion of the Internet datagram, in other words the protocol that resides above IP in the protocol stack and which has passed the datagram on to IP. Typical values are 0x0806 for ARP and 0x8035 for RARP. (0x meaning ‘hex’.) .KGJKXINKIQY[S HOZY This is a checksum on the header only, referred to as a ‘standard Internet checksum’. Since some header fields change (e.g. TTL), this is recomputed and verified at each point that the IP header is processed. It is not necessary to cover the data portion of the datagram, as the protocols making use of IP, such as ICMP, IGMP, UDP and TCP, all have a checksum in their headers to cover their own header and data. To calculate it, the header is divided up into 16-bit words. These words are then added together (normal binary addition with carry) one by one, and the interim sum stored in a 32-bit accumulator. When done, the upper 16 bits of the result is stripped off and added to the lower 16 bits. If, after this, there is a carry out to the 17th bit, it is carried back and added to bit 0. The result is then truncated to 16 bits. 9U[XIKGTJJKYZOTGZOUTGJJXKYYKY HOZYKGIN These are the 32-bit IP addresses of both the origin and the destination of the datagram. 6GIQKZLXGMSKTZGZOUT It should be clear by now that IP might often have difficulty in sending packets across a network since, for example, Ethernet can only accommodate 1500 octets at a time and X.25 is limited to 576. This is where the fragmentation process comes into play. The relevant field here is ‘fragment offset’ (13 bits) while the relevant flags are DF (don’t fragment) and MF (more fragments). Consider a datagram consisting of an IP header followed by 3500 bytes of data. This cannot be transported over an Ethernet network, so it has to be fragmented in order to ‘fit’. The datagram will be broken up into three separate datagrams, each with their own IP header, with the first two frames around 1500 bytes and the last fragment around 500 bytes. The three frames will travel to their destination independently, and will be recognized as fragments of the original datagram by virtue of the number in the identifier /TZKXTKZRG_KXVXUZUIURY field. However, there is no guarantee that they will arrive in the correct order, and the receiver needs to reassemble them. For this reason the fragment offset field indicates the distance or offset between the start of this particular fragment of data, and the starting point of the original frame. One problem though – since only 13 bits are available in the header for the fragment offset (instead of 16), this offset is divided by 8 before transmission, and again multiplied by 8 after reception, requiring the data size (i.e. the offset) to be a multiple of 8 – so an offset of 1500 won’t do. 1480 will be OK since it is divisible by 8. The data will be transmitted as fragments of 1480, 1480 and finally the remainder of 540 bytes. The fragment offsets will be 0, 1480 and 2960 bytes respectively, or 0, 185 and 370 – after division by 8. Incidentally, another reason why the data per fragment cannot exceed 1480 bytes for Ethernet, is that the IP header has to be included for each datagram (otherwise individual datagrams will not be routable) and hence 20 of the 1500 bytes have to be forfeited to the IP header. The first frame will be transmitted with 1480 bytes of data, fragment offset = 0, and MF (more flag) = 1 The second frame will be transmitted with the next 1480 bytes of data, fragment offset = 185, and MF = 1 The last third frame will be transmitted with 540 bytes of data, fragment offset = 370, MF = 0. Some protocol analyzers will indicate the offset in hexadecimal, hence it will be displayed as 0xb9 and 0x172, respectively. For any given type of network the packet size cannot exceed the so-called MTU (maximum transmission unit) for that type of network. The following are some default values: 16 Mbps (IBM) token ring: 17 914 (bytes) 4 Mbps (IEEE802.5) token ring 4464 FDDI 4352 Ethernet/ IEEE802.3 1500 X.25 576 PPP (low delay) 296 The fragmentation mechanism can be checked by doing a ‘ping’ across a network, and setting the data (–l) parameter to exceed the MTU value for the network. Figure 6.16 IPv4 fragmentation 6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM /TZKXTKZVXUZUIUR\KXYOUT/6\/6TM /TZXUJ[IZOUT IPng (‘IP new generation’), as documented in RFC 1752, was approved by the Internet Engineering Steering Group in November 1994 and made a Proposed Standard. The formal name of this protocol is IPv6 (‘IP version 6’). After extensive testing, IANA gave permission for its deployment in mid-1999. IPv6 is an update of IPv4, to be installed as a ‘backwards compatible’ software upgrade, with no scheduled implementation dates. It runs well on high performance networks such as ATM, and at the same time remains efficient enough for low bandwidth networks such as wireless LANs. It also makes provision for Internet functions such as audio broadcasting and encryption. Upgrading to and deployment of IPv6 can be achieved in stages. Individual IPv4 hosts and routers may be upgraded to IPv6 one at a time without affecting any other hosts or routers. New IPv6 hosts and routers can be installed one by one. There are no pre- requisites to upgrading routers, but in the case of upgrading hosts to IPv6 the DNS server must first be upgraded to handle IPv6 address records. When existing IPv4 hosts or routers are upgraded to IPv6, they may continue to use their existing address. They do not need to be assigned new IPv6 addresses, neither do administrators have to draft new addressing plans. The simplicity of the upgrade to IPv6 is brought about through the transition mechanisms built into IPv6. They include the following: • The IPv6 addressing structure embeds IPv4 addresses within IPv6 addresses, and encodes other information used by the transition mechanisms • All hosts and routers upgraded to IPv6 in the early transition phase will be ‘dual’ capable (i.e. implement complete IPv4 and IPv6 protocol stacks) • Encapsulation of IPv6 packets within IPv4 headers will be used to carry them over segments of the end-to-end path where the routers have not yet been upgraded to IPv6 The IPv6 transition mechanisms ensure that IPv6 hosts can inter-operate with IPv4 hosts anywhere in the Internet up until the time when IPv4 addresses run out, and allows IPv6 and IPv4 hosts within a limited scope to inter-operate indefinitely after that. This feature protects the huge investment users have made in IPv4 and ensures that IPv6 does not render IPv4 obsolete. Hosts that need only a limited connectivity range (e.g., printers) need never be upgraded to IPv6. /6\U\KX\OK] The changes from IPv4 to IPv6 fall primarily into the following categories: • Expanded routing and addressing capabilities IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes, and simpler auto-configuration of addresses • Anycasting A new type of address called an anycast address is defined; to identify sets of nodes where a packet sent to the group of anycast addresses is delivered /TZKXTKZRG_KXVXUZUIURY to (only) one of the nodes. The use of anycast addresses in the IPv6 source route allows nodes to control the path that their traffic flows • Header format simplification Some IPv4 header fields have been dropped or made optional, to reduce the effort involved in processing packets. The IPv6 header was also kept as small as possible despite the increased size of the addresses. Even though the IPv6 addresses are four times longer than the IPv4 addresses, the IPv6 header is only twice the size of the IPv4 header • Improved support for options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future • Quality-of-service capabilities A new capability is added to enable the labeling of packets belonging to particular traffic ‘flows’ for which the sender requests special handling, such as special ‘quality of service’ or ‘real-time’ service • Authentication and privacy capabilities IPv6 includes extensions that provide support for authentication, data integrity, and confidentiality /6\NKGJKXLUXSGZ Figure 6.17 IPv6 header The header contains the following fields: <KX HOZY The Internet protocol version number, viz. 6. )RGYY HOZY Class value. This replaces the 4-bit priority value envisaged during the early stages of the design and is used in conjunction with the Flow label. 6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM ,RU]RGHKR HOZY A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. This is an optional field to be used if specific non-standard (‘non-default’) handling is required to support applications that require some degree of consistent throughput in order to minimize delay and/or jitter. These types of applications are commonly described as ‘multi-media’ or ‘real-time’ applications. The flow label will effect the way the packets are handled but will not influence the routing decisions. 6G_RUGJRKTMZN HOZY The payload is the rest of the packet following the IPv6 header, in octets. The maximum payload that can be carried behind a standard IPv6 header cannot exceed 65 536 bytes. With an extension header this is possible, the datagram is then referred to as a Jumbo datagram. Payload length differs slightly from the IPv4 in that the ‘total length’ field does not include the header. 4K^ZNJX HOZY This identifies the type of header immediately following the IPv6 header, using the same values as the IPv4 protocol field. Unlike IPv4, where this would typically point to TCP or UDP, this field could either point to the next protocol header (TCP) or to the next IPv6 extension header. Figure 6.18 Header insertion and ‘next header’ field .UVROSOZ HOZY This is an unsigned integer, similar to TTL in IPv4. It is decremented by 1 by each node that forwards the packet. The packet is discarded if hop limit is decremented to zero. 9U[XIKGJJXKYY HOZY This is the address of the initial sender of the packet. *KYZOTGZOUTGJJXKYY HOZY This is address of the intended recipient of the packet, which is not necessarily the ultimate recipient, if an optional routing header is present. . transmitted as fragments of 1480, 1480 and finally the remainder of 540 bytes. The fragment offsets will be 0, 1480 and 2960 bytes respectively, or 0, 185 and 370 – after division by 8. Incidentally,. such as ATM, and at the same time remains efficient enough for low bandwidth networks such as wireless LANs. It also makes provision for Internet functions such as audio broadcasting and encryption to and deployment of IPv6 can be achieved in stages. Individual IPv4 hosts and routers may be upgraded to IPv6 one at a time without affecting any other hosts or routers. New IPv6 hosts and