4.7 IPv6
In the early 1990's the Internet Engineering Task force began an effort
to develop a successor to the IPv4 protocol. A prime motivation for
this effort was the realization that the 32-bit IP address space was beginning
to be used up, with new networks and IP nodes being attached to the Internet
(and being allocated unique IP addresses) at a breathtaking rate.
To respond to this need of a large IP address space, a new IP protocol,
IPv6, was developed. The designers of IPv6 also took this opportunity to
tweak and augment other aspects of IPv4, based on the accumulated operational
experience with IPv4.
The point in time when IPv4 addresses would have been completely allocated
(and hence no new networks could have attached to the Internet) was the
subject of considerable debate. Based on current trends in address
allocation, the estimates of the two leaders of the IETF's Address Lifetime
Expectations working group were that addresses would become exhausted in
2008 and 2018 respectively [Solensky 1996]
. In 1996, the American Registry for Internet Number (ARIN)
reported that all of the IPv4 class A addresses have been assigned, 62%
of the class B addresses have been assigned, and 37% of the class C addresses
have been assigned [ARIN 1996]. While
these estimates and numbers suggested that a considerable amount of time
might be left until the IPv4 address space became exhausted, it was realized
that considerable time would be needed to deploy a new technology on such
an extensive scale, and so the "Next Generation IP" (IPng) effort [Bradner
1996], [RFC1752]was begun. An excellent on-line
source of information about IPv6 is The
IP Next Generation Homepage. An excellent book is also available on
the subject [Huitema 1997].
4.7.1 IPv6 Packet Format
The format of the IPv6 packet is shown in Figure 4.7-1. The most important
changes introduced in IPv6 are evident in the packet format:
-
Expanded addressing capabilities. IPv6 increases the size
of the IP address from 32 to 128 bits. This insures that the world
won't run out of IP addresses. Now, every grain of sand on the planet can
be IP-addressable. In addition, the address space contains
new hierarchical structure, allocating portions of the enlarged address
space to geographical regions [RFC 1884].
In addition to unicast and multicast addresses, a new type of address,
called an anycast address, has also been introduced, which allows
a packet addressed to an anycase address to be delivered to any one of
a group of hosts. This feature could be used, for example,
to send an HTTP GET to the nearest of a number of mirror sites that contain
a given document).
-
A streamlined 40 byte header. As discussed below, a number
of IPv4 fields have ben dropped or made optional. The resulting 40-byte
fixed-length header allows for faster processing of the IP packet.
A new encoding of options allows for more flexible options processing.
-
Flow labeling and priority. IPv6 has an elusive definition
of a "flow." [RFC 1752] and [RFC
2460] state this allows "labeling of packets belonging to particular
flows for which the sender requests special handling, such as a non-default
quality of service or real-time service." For example, audio and
video transmission might likely be treated as a flow. On the other
hand, the more traditional applications, such as file transfer and
email might not be treated as flows. It is possible that the traffic
carried by a high-priority user (e.g., someone paying for better service
for their traffic) might also be treated as a flow. What is clear,
however, is that the designers of IPv6 foresee the eventual need to be
able to differentiate among the "flows," even if the exact meaning of a
flow has not yet been determined. The IPv6 header also has a 4-bit
priority
field. This field, as the TOS field in IPv4, can be used to give priority
to certain packets within a flow, or it can be used to give priority to
datagrams from certain applications (e.g., ICMP packets) over packets from
other applications (e.g., network news).
Figure 4.7-1: IPv6 packet format
The IPv6 packet format is shown in Figure 4.7-1. As noted above,
a comparison of Figure 4.7-1 with Figure 4.4-8 reveals the simpler, more
streamlined structure of the IPv6 packet. The following packet fields
are defined in IPv6:
-
version. This four bit field identifies the IP version number.
Not surprisingly, IPv6 carries a value of "6" in this field. Note
that putting a "4" in this field does not create a valid IPv4 packet (if
it did, life would be a lot simpler -- see the discussion below regarding
the transition from IPv4 to IPv6.
-
priority. This four bit field is similar in spirit to the
ToS field we saw in IP version 4. [RFC 2460]
states that values 0 through 7 are to be used for priority among traffic
that is congestion-controlled (i.e., for which the source will back off
on detection of congestion), while values 8 through 15 are used for non-congestion
controlled traffic, such as constant bit rate real-time traffic.
-
flow label. As discussed above, this field is used to identify
a "flow" of packets.
-
payload length. This 16-bit value is treated as an unsigned integer
given the number of bytes in the IPv6 packet following the fixed length,
40 byte packet header.
-
next header. This field identifies the protocol to which the
contents (data field) of this packet will be delivered (e.g., to TCP or
UDP). The field uses the same values as the Protocol field in the
IPv4 header.
-
hop limit. The contents of this field are decremented by one
by each router that forward the packet. If the hop limit count reaches
zero, the packet is discarded.
-
source and destination address. An IP v6 address has the following
structure:
-
data. This is the payload portion of the IPv6 packet.
When the packet reaches its destination, the payload will be removed from
the IP packet and passed on to the protocol specified in the nex header
field.
The discussion above identified the purpose of the fields that are
included in the IPv6 packet. Comparing the IPv6 packet format in
Figure 4.7-1 with the IPv4 packet format that we saw earlier in Figure
4.4-8, we notice that several fields appearing in the IPv4 packet are no
longer present in the IPv6 packet:
-
Fragmentation/Reassembly. IPv6 does not provide for fragmentation
and reassembly. If an IPv6 packet received by a router is too large
to be forwarded over the outgoing link, the router simply drops the packet
and sends a "Packet Too Big" ICMP error message (see below)
back to the sender. The sender can then resend the data, using a smaller
IP packet size. Fragmentation and reassembly is a time-consuming
operating; removing this functionality from the routers and placing it
squarely in the end systems considerably speeds up IP forwarding
within the network.
-
Checksum. Because the transport layer (e.g, TCP and UDP) and data
link (e.g., Ethernet) protocols in the Internet layers perform checksumming,
the designers of IP probably felt that this functionality was sufficiently
redundant in the network layer that it could be removed. Once again,
fast processing of IP packets was a central concern. Recall from
our discussion of IPv4 in section 4.4.1, that since the IPv4 header contains
a TTL field (similar to the hop limit field in IPv6), the IPv4 header checksum
needed to be recomputed at every router. As with fragmentation and
reassembly, this too was a costly operation in IPv4.
-
Options. An options field is no longer a part of the standard IP
header. However, it has not gone away. Instead, the options field
is one of the possible "next headers" pointed to from within the IPv6 header.
That is, just as TCP or UDP protocol headers can be the next header within
an IP packet, so too can an options field. The removal of the options filed
results in a fixed length, 40 byte IP header.
A New ICMP for IPv6
Recall from our discussion in Section 4.3, that the ICMP protocol is used
by IP nodes to report error conditions and provide limited information
(e.g., the echo reply to a ping message) to an end system.
A new version of ICMP has been defined for IPv6 in [RFC
1885]. In addition to reorganizing the existing ICMP type and
code definitions, ICMPv6 also added new types and codes required by the
new IPv6 functionality. These include the "Packet Too Big" type,
and an "unrecognized IPv6 options" error code. In addition, ICMPv6
subsumes the functionality of the Internet Group Management Protocol (IGMP)
that we will study in Section 4.8. IGMP, which is used to manage a host's
joining and leaving of so-called multicast groups, was previously a separate
protocol from ICMP in IPv4.
5.7.2 Transitioning from IPv4 to IPv6
Now that we have seen the technical details of IPv6, let us consider a
very practical matter: how will the public Internet, which is based on
IPv4, be transitioned to IPv6? The problem is that while new IPv6-capable
systems can be made "backwards compatible", i.e., can send, route, and
receive IPv4 packets, already deployed IPv4-capable systems are not capable
of handling IPv6 packets. Several options are possible.
One option would be to declare a "flag day" - a given time and date
when all Internet machines would be turned off, be upgraded from IPv4 to
IPv6. The last major technology transition (from using NCP
to using TCP for reliable transport service) occurred almost 20 years ago.
Even back then [RFC 801], when the Internet was
tiny and still being administered by a small number of "wizards," it was
realized the such a flag day was not possible. A flag day involving
hundreds of millions of machines and millions of network administrators
and users is even more unthinkable today. [RFC
1993] describes two approaches (which can be used either alone or together)
for gradually integrating IPv6 hosts and routers into an IPv4 world (with
the long term goal, of course, of having all IPv4 nodes eventually transition
to IPv6).
Probably the most straightforward way to introduce IPv6-capable nodes
is a dual stack approach, where IPv6 nodes also have a complete
IPv4 implementation as well. Such a node, referred to as IPv6/IPv4
node in [RFC 1993], the ability to send
and receive both IPv4 and IPv6 packets. When interoperating with
an IPv4 node, an IPv6/IPv4 node can use IPv4 packets; when interoperating
with an IPv6 node, it can speak IPv6. IPv6/IPv4 nodes must have both
IPv6 and IPv4 addresses. They must furthermore be able to determine
whether another node is IPv6-capable or IPv4-only. This problem can
be solved using the DNS (see Chapter 2), which can return an IPv6 address
if the node name being resolved is IPv6 capable, or otherwise return an
IPv4 address. Of course, if the node issuing the DNS request in only
IPv4 capable, the DNS returns only an IPv4 address.
Figure 4.7-3: A dual stack approach
In the dual stack approach, if either the sender of the receiver is
only IPv4-capable, IPv4 packets must be used. As a result, it is
possible that two IPv6-capable nodes can end, in essence, sending IPv4
packets to each other. This is illustrated in Figure 4.7-3.
Suppose node A is IPv6 capable and wants to send an IP packet to
node E, which is also IPv6-capable. Nodes A and B can exchange an
IPv6 packet. However, node B must create an IPv4 packet to send to
C. Certainly, the data field of the IPv6 packet can be copied into the
data field of the IPv4 packet and appropriate address mapping can be done.
However, in performing the conversion from IPv6 to IPv4, there will be
IPv6-specific fields in the IPv6 packet (e.g., the flow identifier field)
that have no counterpart in IPv4. The information is these fields
will be lost. Thus, even though E and F can exchange IPv6 packets,
the arriving IPv4 packets at E from D do not contain all of the fields
that were in te original IPv6 packet sent from A. .
An alternative to the dual stack approach, also discussed in [RFC
1993], is known as tunneling. Tunneling can solve the
problem noted above, allowing, for example, E to receive the IPv6 packet
originated by A. The basic idea behind tunneling is the following.
Suppose two IPv6 nodes (e.g, B and E in Figure 4.7-3) want to interoperate
using IPv6 packets, but are connected to each other by intervening IPv4
routers. We refer to the intervening set of IPv4 routers between
two IPv6 routers as a tunnel, as illustrated in Figure 4.7-4.
With tunneling, the IPv6 node on the sending side of the tunnel (e.g.,
B) takes the entire IPv6 packet, and puts it in the data (payload)
field of an IPv4 packet. This IPv4 packet is then addressed to the
IPv6 node on the receiving side of the tunnel (e.g., E) and sent to the
first node in the tunnel (e.g., C). The intervening IPv4 routers
in the tunnel route this IPv4 packet amongst themselves, just as they would
any other packet, blissfully unaware that the IPv4 packet itself contains
a complete IPv6 packet. The IPv6 node on the receiving side of the
tunnel eventually receives the IPv4 packet (it is the destination of the
IPv4 packet!), determines that the IPv4 packet contains an IPv6 packet,
extracts the IPv6 packet and then routes the IPv6 packet exactly as it
would if it had received the IPv6 packet from a directly-connected IPv6
neighbor.
Figure 4.7-4: Tunneling
We end this section by mentioning that there is currently some doubt
about whether IPv6 will make significant inroads into the Internet in the
near future (2000-2002) or even ever at all [Garber
1999]. Indeed, at the time of this writing, a number of North American
ISPs have said they don't plan to buy IPv6-enabled networking equipment.
These ISPs say that there is little customer demand for IPv6's capabilities
when IPv4, with some patches (such as network address translator boxes),
is working well enough. On the other hand, there appears to be more interest
in IPv6 in Europe and Asia. Thus the fate of IPv6 remains an open question.
One important lesson that we can learn from the IPv6 experience is that
it is enormously difficult to change network-layer protocols. Since the
early 1990s, numerous new network-layer protocols have been trumpeted as
the next major revolution for the Internet, but most of these protocols
have had minor (if any) penetration to date. These protocols include IPv6,
multicast protocols (Section 4.8), and resource reservation protocols (Section
6.9). Indeed, introducing new protocols into the network layer is like
replacing the foundation
of a house - it is difficult to do without tearing the whole house
down or at least temporarily relocated the house's residents. On the other
hand, the Internet has witnessed rapid deployment of new protocols at the
application layer. The classic example, of course, is HTTP and the Web;
other examples include audio and video streaming and chat. Introducing
new application layer protocols is like adding a new layer of paint to
a house -- it is relatively easy to do, and if you choose an attractive
color, others in the neighborhood will copy you. In summary, in the future
we can expect to see changes in the Internet's network layer, but these
changes will likely occur on a time scale that is much slower than the
changes that will occur at the application layer.
References
[Garber 1999] L. Garber, 'Steve Deering on
IP Next Generation," IEEE Computer, pp. 11-13, April 1999
[Gilligan 1996] R. Gilligan R. Callon,
"IPv6 Transition Mechanisms Overview," in in IPng: Internet Protocol
Next Generation (S. Bradner, A. Mankin, ed), Adddison Wesley, 1996.
[Huitema 1997] C. Huitema, Ipv6 : The
New Internet Protocol, Prentice Hall, 1997
[RFC 801] J. Postel, "NCP/TCP Transition Plan,"
RFC
801, Nov. 1981.
[RFC 1752] S. Bradner, A. Mankin, "The Recommendations
for the IP Next Generation Protocol," RFC
1752, Jan. 1995.
[RFC 2460] S. Deering and R. Hinden,
"Internet Protocol, Version 6 (IPv6) Specification," RFC
2460, December 1998.
[RFC 1884] R. Hinden, S. Deering, "IP Version
6: addressing architecture",
RFC 1884, December 1995.
[RFC 2463] A. Conta, S. Deering, "Internet
Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6),
RFC
2463, December 1998.
[RFC 1993] R. Gilligan, E. Nordmark, "Transition
Mechanisms for IPv6 Hosts and Routers," RFC
1933, April 1996.
[Solensky 1996] F. Solensky, "IPv4 Address
Lifetime Expectations," in IPng: Internet Protocol Next Generation (S.
Bradner, A. Mankin, ed), Adddison Wesley, 1996.
Copyright Keith W. Ross and Jim Kurose, 1996-2000.
All Rights Reserved.