a dependency on other hosts or routers being upgraded.
ÔÇó Low start-up costs: little or no preparation work is needed in order to upgrade existing
IPv4 systems to IPv6, or to deploy new IPv6 systems.
ÔÇó Quality of service capabilities: a new capability is added to enable the labelling of
packets belonging to particular traf´¬üc ´¬‚ows for which the sender has requested special
handling, such as non-default QoS or real-time service.
ÔÇó Mobility support: since the end system is identi´¬üed with the end system identi´¬üer (ESI),
in many ways IPv6 makes implementing mobile IP simpler.

5.10.1 The IPv6 header
The IPv6 header is 40 octets in length, with eight ´¬üelds. This can be compared to IPv4,
which has only 20 octets of header but 13 ´¬üelds within it. The IPv6 header is shown in
Figure 5.55 and its ´¬üelds are described in Table 5.14. It can be seen that the following
have been removed:

ÔÇó Header length: since the header of IPv6 is a standard 40 bytes there is no need for a
length indicator.
ÔÇó Fragment offset, identi´¬ücation, ´¬‚ags: these have been moved to the extension headers.
ÔÇó Checksum: this has been removed completely. Error checking is typically duplicated at
other levels of the protocol stack. Requiring routers to perform this check has reduced
performance on todayÔÇ™s Internet. Also, many point-to-point connections are now ´¬übre
and this medium has a very low error rate.
5.10 INTERNET PROTOCOL VERSION 6 (IPv6) 239

5.10.2 Traf´¬üc classes
The 8-bit traf´¬üc class ´¬üeld in the IPv6 header is available for use by originating nodes
and/or forwarding routers to identify and distinguish between different classes or priorities
of IPv6 packets. This is equivalent to the IPv4 type of service byte, which forms the
ÔÇ˜differentiated serviceÔÇ™ for IP packets. The traf´¬üc class ´¬üeld in the IPv6 header is intended
to allow similar functionality to be supported in IPv6. Both IPv4 and IPv6 support the
RSVP protocol. The following general requirements apply to the traf´¬üc class ´¬üeld:

ÔÇó The service interface to the IPv6 service within a node must provide a means for an
upper-layer protocol to supply the value of the traf´¬üc class bits in packets originated
by that upper-layer protocol. The default value must be zero for all 8 bits.
ÔÇó Nodes that support a speci´¬üc (experimental or eventual standard) use of some or all of
the traf´¬üc class bits are permitted to change the value of those bits in packets that they
originate, forward or receive, as required for that speci´¬üc use. Nodes should ignore
and leave unchanged any bits of the traf´¬üc class ´¬üeld for which they do not support a
speci´¬üc use.
240 IP APPLICATIONS FOR GPRS/UMTS

ÔÇó An upper-layer protocol must not assume that the value of the traf´¬üc class bits in a
received packet are the same as the value sent by the packetÔÇ™s source.

5.10.3 Flow labels
The 20-bit ´¬‚ow label ´¬üeld in the IPv6 header may be used by a source to label sequences
of packets for which it requests special handling by the IPv6 routers, such as non-default
QoS or real-time service. Hosts or routers that do not support the functions of the ´¬‚ow
label ´¬üeld are required to set the ´¬üeld to zero when originating a packet, pass the ´¬üeld
on unchanged when forwarding a packet, and ignore the ´¬üeld when receiving a packet.
There may be multiple active ´¬‚ows from a source to a destination, as well as traf´¬üc that
is not associated with any ´¬‚ow. A ´¬‚ow is uniquely identi´¬üed by the combination of a
source address and a non-zero ´¬‚ow label. Packets that do not belong to a ´¬‚ow carry a ´¬‚ow
label of zero. A ´¬‚ow label is assigned to a ´¬‚ow by the ´¬‚owÔÇ™s source node. All packets
belonging to the same ´¬‚ow must be sent with the same source address, destination address
and ´¬‚ow label.

5.10.4 The payload length ´¬üeld
The 16-bit payload length ´¬üeld measures the length, given in octets, of the payload
following the IPv6 header. Any extension headers present are considered part of the
payload, i.e. included in the length count. Payloads greater than 65 535 are allowed,
and these are called jumbo payloads. To indicate a jumbo payload, the value of the
payload length is set to zero, and the actual payload length is carried in a jumbo payload
hop-by-hop option.

5.10.5 The next header ´¬üeld
The 8-bit next header ´¬üeld identi´¬ües the header immediately following the IPv6 header.
This ´¬üeld uses the same value as the IPv4 protocol ´¬üeld, as outlined in RFC 1700.
Examples are shown in Table 5.15.

5.10.6 The hop limit
The 8-bit hop limit is decremented by one by each node that forwards the packet. If
the hop limit equals zero, the packet is discarded and an error message is returned. This
allows 256 routers to be traversed from source to destination. It actually replaces the TTL
´¬üeld in the IPv4 header, which was initially included in IPv4 to give an indication of the
number of seconds that the packet had been alive. The ´¬üeld was never used for this; it in
fact also counted the hops (intermediate nodes) but unfortunately the name stuck.
5.10 INTERNET PROTOCOL VERSION 6 (IPv6) 241

The source address is a 128-bit ´¬üeld that identi´¬ües the originator of the packet.

5.10.8 The destination address

The destination address ´¬üeld is a 128-bit ´¬üeld that identi´¬ües the intended recipient of the
packet. Although this is usually the ultimate recipient, if the routing header is present this
may not be the case.

The IPv6 design simpli´¬üed the existing IPv4 header by placing many of the existing
´¬üelds in optional headers. In this way, typical packet transfer is not complicated by inter-
mediate routers having to check all the ´¬üelds. Where they are needed, the more complex
conditions are still provided for via the extension header with the obvious overhead. An
IPv6 packet, which consists of an IPv6 packet plus its payload, may consist of zero, one,
or more extension headers. Figure 5.56 shows an example of the next header ´¬üeld. The
original next header ´¬ürst indicates the value 00. This means that the ´¬ürst extension is a
hop-by-hop extension. The hop-by-hop extension has a value of 43, indicating that the
next extension is a routing extension. This routing extension has 06 in its next header
´¬üeld to indicate that the next header is the TCP header. Each of the extension headers is
an integer multiple of 8 octets long to maintain alignment for subsequent headers. The
hop-by-hop options header carries information that must be examined and processed by
every node along a packetÔÇ™s delivery path, including the destination node. As a result,
the hop-by-hop options header, when present, must immediately follow the IPv6 header.
The other extension headers are not examined or processed by any node along a packetÔÇ™s
delivery path, until the packet reaches its intended destination(s). When processed, the
operation is performed in the order in which the headers appear in the packet.
242 IP APPLICATIONS FOR GPRS/UMTS

IPv4 address are typically represented in dotted decimal notation. As such, a 32-bit address
is divided into four 8-bit sections separated by periods. Each section is represented by a
decimal number between 0 and 255, for example 152.226.51.126.
This would be a cumbersome way of representing IPv6 addresses since they are 128
bits long, so a different method of representation is required. This new method is speci´¬üed
in the addressing architecture document, RFC 2373. The preferred method of representa-
tion is:
x:x:x:x:x:x:x:x

where each x represents 16 bits, and each of those 16-bit sections is de´¬üned in hexadec-
imal. For example, an IPv6 address could be of the form:

DEFC : A9BE : 1236 : DE89 : D7FE : 4535 : 908A : 4DEF

Note that each of the 16-bit sections is separated by colons, and that four hexadecimal
numbers are used to represent each 16-bit section. If any sections contain leading zeros,
then those zeros can be omitted. For example:

If long strings of zeros appear in an address, a double colon ÔÇ˜::ÔÇ™ may be used to indicate
multiple groups of 16 bits of zeros, which further simpli´¬ües the example shown above:

DEC5 :: 9 : 600 : 3EDC : AB41

The use of the double colon can only appear once in an address, although it may be used
to compress either the leading or trailing zeros in an address. For example, a loopback
address of:
0:0:0:0:0:0:0:1

could be simpli´¬üed as:
:: 1

5.10.10 The transition from IPv4 to IPv6
Figure 5.57, shows how IPv4 and IPv6 can coexist on an Ethernet network. The type ´¬üeld
identi´¬ües which protocol is in the payload, with 0x0800 for IPv4 and 0x86DD for IPv6.
The bene´¬üts derived from a new protocol must also be balanced by the costs associated
with making a transition from the existing systems. These logistical and technical issues
have been addressed in RFC 1933, ÔÇ˜Transition Mechanisms for IPv6 Host and RoutersÔÇ™.
The developers of IPv6 recognized that not all systems would upgrade from IPv4 to
IPv6 in the immediate future, and that for some systems, that upgrade may not be for
years. To complicate matters, most internetworks are heterogeneous systems, with various
routers, hosts etc. manufactured by different vendors. If such a multivendor system were
to be upgraded at one time, IPv6 capabilities would be required on all of the individual
elements before the large project could be attempted. Another (much larger) issue is the
worldwide Internet, which operates across 24 different time zones, Upgrading this system
in a single process would be even more dif´¬ücult.
Given the above constraints, it therefore becomes necessary to develop strategies for
IPv4 and IPv6 to coexist, until such time as IPv6 becomes the preferred option. At the time
of writing, two mechanisms for this coexistence have been proposed: a dual IP layer and
IPv6 over IPv4 tunnelling. These two alternatives are discussed in the following sections.

5.10.11 Dual IP layer
The simplest mechanism for IPv4 and IPv6 coexistence is for both of the protocol stacks
to be implemented on the same station. The station, which could be a host or a router,