<<

. 51
( 132 .)



>>

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


0 16 31
Version Traffic Class Flow Label
Payload Length Next Header Hop Limit


Source Address (128 bits)



Destination Address (128 bits)



Figure 5.55 IPv6 header format

Table 5.14 IPv6 header ¬elds
Header Comment
Version 4-bit IP version number = 6
Traf¬c class 8-bit traf¬c class ¬eld
Flow label 20-bit ¬‚ow label
Payload length 16-bit integer to indicate length of payload in bytes
Next header 8-bit selector. Identi¬es the type of header immediately
following the IPv6 header
Hop limit 8-bit unsigned integer. Decremented by 1 by each node
that forwards the packet
Source address 128-bit address of the originator of the packet
Destination address 128-bit address of the intended recipient of the packet
(possibly not the ultimate recipient, if a routing header
is present)


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


Table 5.15 Example IPv6 next header ¬elds
Value Header
0 Hop-by-hop options
1 ICMPv4
4 IP in IP (encapsulation)
6 TCP
17 UDP
43 Routing
50 Encapsulating security payload
51 Authentication
58 ICMPv6
59 None (no next header)
60 Destination options


5.10.7 The source address

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


0 16 31
Version Traffic Class Flow Label
Payload Length Next Header 00 Hop Limit


Source Address (128 bits)




Destination Address (128 bits)


Next Header 43
Hop by Hop Extension

Next Header 06
Routing Extension


TCP Header


Figure 5.56 Example header extensions


5.10.9 IPv6 address representation

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:

DEC5 : 0000 : 0000 : 0000 : 0009 : 0600 : 3EDC : AB41

may be simpli¬ed to:

DEC5 : 0 : 0 : 0 : 9 : 600 : 3EDC : AB41
5.10 INTERNET PROTOCOL VERSION 6 (IPv6) 243


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,


Dest Add Source Add 0800 IPv4 packet FRC


Dest Add Source Add IPv6 packet FRC
86DD


Figure 5.57 Example of Ethernet carrying IP
244 IP APPLICATIONS FOR GPRS/UMTS

<<

. 51
( 132 .)



>>