IPv6
Elliot Schwartz <elliot@mit.edu>
IPv6 is defined in [RFC1883]. (IPv4 is defined in
[RFC791].)
More current information can be find on the IPv6 home page [IPNG].
Packet Fields
-
Version
The version field exists for the same purpose as in IPv4, namely to
differentiate between different versions of the protocol. Obviously it
carries the value of "6" for all IPv6 packets. Version number 5 is allocated
to the Internet Stream Protocol [RFC1819].
-
Traffic Class
This is similar to the Type of Service (ToS) bits in IPv4, except that
it tries to describe the type of traffic rather than the type
of service. Of course, the ToS bits weren't used in IPv4, so why bother
including something similar in IPv6? Well, people have a better idea of
how to provide different types of service now, through mechanisms such
as traffic scheduling, weighted fair queuing, etc. The IETF
is working on a Differentiated Services system, but there's nothing in
practice yet.
-
Flow Label
This is used to label a "flow" of packets. On problem with a packet
switching network is that there's no good way to tell if a bunch of separate
packets are related to each other. Yes, you can try to guess from the upper
level information, but that's breaking the abstraction barrier. The specific
use it was intended for is so that a flow can be given a special quality
of service, but it could also be used for other statistics or optimizations.
It's still experimental, but could be used immediately for applications
like Ipsilon's IP switching, which
tries to recognize flows and fast-track them over ATM without looking at
the IP header for each hop. It could also be used to cache routes or other
information in routers, which makes it more similar to circuit switching.
If it is used, the flow label needs to be chosen randomly, so that it can
be used as a hash value in routers. An Informational RFC discusses using
the Flow Label field [RFC1809].
-
Payload Length
This is the length of the packet not including the IPv6 header. It
replaces the Total Length field in IPv4. Unlike IPv4, IPv6 headers are
of a fixed length, and there's no point in adding a constant to the length
field.
-
Next Header
This is like the Protocol field from IPv4 - it identifies the higher
level protocol. However, unlike IPv4, this is not always a transport layer
protocol like TCP or UDP. It takes on special values which are used to
implement the IPv6 extension and option mechanisms.
-
Hop Limit
This is like the TTL (Time To Live) field from IPv4 - it's used to
minimize the resources that a packet consumes in the event of a routing
loop. Its name has been changed to reflect the actual usage of the field.
Namely, it is decremented every hop, rather than every second as was originally
intended.
-
Source Address
-
Destination Address
These have the same purpose in IPv4, but have been expanded to 128
bits. We'll talk more about addressing later.
Also notice that unlike IPv4 there's no header checksum in the IP header.
Basically, it was thought that it didn't provide enough utility to justify
its existance. Any protocol that really cared about reliability was expected
to provide a higher level checksum mechanism anyhow, and with Level 2 technologies
being very good and/or having their own checksums, the IP checksum didn't
detect many errors.
Extension Headers
Extension Headers contain optional information. These exist between the
IPv6 header and the transport layer header, so that they're only read when
necessary (typically, just at the end nodes, with the exception of Hop-by-Hop
options, which must come first so that they can be read at every node).
There's only a small number of extension headers, and they're not to be
added lightly, since all hosts need to understand every header.
Most extension headers look similar, having a Next Header field (just like
the IPv6 field), a length field (basically a pointer to the next header),
and header-specific data.
-
Hop-by-Hop Options
This is the exception to the rule that headers are only read at the
end nodes, since it needs to be read by every router. It contains options
for each router / host to process.
-
Routing
The Routing header allows the host to specify alternate routing (i.e.
a list of routers the packet should go through can be specified to override
the normal routing table lookups). This works similarly to the source routing
option in IPv4.
-
Fragment
This contains information used for fragmentation and reassembly, which
is necessary if the size of a packet is bigger than the maximum size supported
by a subnet on the path the packet takes. Unlike IPv4, fragmentation is
only performed by the source node; routers which get oversized packets
just send back error messages, and the source node is expected to deal
with it. Just like IPv4 it contains a Fragment Offset, Idenfitication,
and a More Fragments bit. Unlike IPv4, it doesn't have a Don't Fragment
bit, since routers wont fragment anyhow.
-
Destination Options
This is similar to Hop-by-Hop Options, except that it's only inspected
/ acted upon by the destination node.
-
Authentication
-
Encapsulating Security Payload
These provide IP Security services. (see [RFC1825],
[RFC1826], and [RFC1827])
Options
The Hop-by-Hop Options and Destination Options headers contain one or more
options. Not all hosts need to understand all options. All options have
the following fields:
-
Option Type
This indicates what should happen if the option isn't recognized by
the host. The different possibilities are skip the option and continue,
discard the packet, discard the packet and send an error message back to
the host, and discard the packet but only send an error if the packet was
sent to a unicast address.
-
Option Data Length - the length of the data field in octets (bytes).
-
Option Data - the variable sized data field, specific to the option.
Therre are only a few options currently defined:
-
Pad1
-
PadN
-
Jumbo Payload
Addressing
Unlike IPv4, there are no broadcast addresses in IPv6 - multicast address
obsolete this. Also, the lower 48 bits of a unicast IPv6 address are taken
from the Level 2 / MAC address of the machine's interface card. This unique
idenifier is used in autoconfiguration.
Addressing is documented in [RFC1885].
-
Bigger Addresses
IPv6 has much bigger addresses than IPv4. Specifically, 128 bit addresses
rather than 32 bit addresses. The number of 128-bit addresses is equal
to the number of 32-bit addresses squared squared, or 2^128=340282366920938463463374607431768211456
addresses. (2^32 is on the order of the number of people on earth).
-
Anycast Addresses
These identify a set of interfaces, similar to multicast addresses.
However, packets are only delivered to the nearest interface, not
to all interfaces. "Nearest" is according to some metric used in the routing
protocols. There are a number of ways to implement this, but none are necessarily
practical. Still, anycast addresses still have the potential to be handy
for things like resource discovery and distributed databases. See [RFC1546]
for more information .
-
Representation
The written representation of an IPv6 address is 8 colon separated
4-digit hexadecimal numbers. Left aligned zeros in each number can be omitted.
Ajacent zero numbers in the middle of an address can be abbreviated with
:: (i.e. it means, "fill in the appropriate number of zeros here to pad
the address out to the left and right"). The loopback address is ::1. Examples
of IPv6 addresses are:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:417A
1080::8:800:200C:417A
-
IPv4 Compatibility
There are two kinds of addresses used for IPv4 compatibility. The first
kind, which look like ::18.208.0.50 are used for tunneling IPv6
over an IPv4 routing infrastructure. The second kind, ::FFFF:18.208.0.50
for example, are used for representing IPv4 only hosts. Most initial IPv6
implementations will support both tunneling over IPv4, and communicating
with IPv4 hosts directly. Transition mechanisms for IPv6 are discussed
in [RFC1933].
-
Site- and Link- Local Addresses
Link-local addresses can only be used on the local link, while site-local
addresses can only be used within the organization. Link-local addresses
are used mostly for autoconfiguartion
and neighbor discovery (see [RFC1970]), or if an
organization is small enough that it doesn't need to have any routers.
Site-local addresses are used for networks that are not yet connected to
the global Internet, in a similar way to the IPv4 scheme described in [RFC1918].
Autoconfiguration
The purpose of autoconfiguration is to reduce the amount of setup and configuration
that goes into hosts. If you've set up an IPv4 host, you know it can be
a pain to type in the numbers, and autoconfiguration gets rid of this.
Perhaps more important, it also removes state from the hosts so that if
something like a change in default router or IP address is needed, it can
be performed without user intervention. Autoconfiguration is described
in [RFC1971].
The following procedure is used for autoconfiguration:
-
Choose Link-Local Address
This is done by prepending a well-known link-local prefix (FE80::0:)
to the unique interface MAC address.
-
Perform Duplicate Address Detection
This is part of Neighbor Discovery. The host sends a Neighbor Solicitation
message, and waits to make sure it doesn't get a response from a host (which
would mean someone was using the address already).
-
Send Router Solicitation
This asks the router to provide information in the form of a Router
Advertisment packet.
-
Receive Router Advertisement
This is sent by routers periodically, or in response to a Router Solicitation
packet. It provides prefixes for address configuration, and other useful
information such as the link MTU, and the lifetime of the information.
-
Choose Global Address...
From the information received.
Reality
-
Current Status
IPv6 and its associated protocols are currently IETF Proposed Standards.
There are currently some implementations in hosts and routers [IPNGIMPL].
However, there's no deployment of IPv6 in any real life networks. Some
testing is being done on the "6Bone" [6BONE].
-
Future
What will come of IPv6? Quite possibly, not very much. To sell
something with such a big transition cost, you really need a good reason
i.e. a carrot on the end of the stick. More addresses was thought to be
the carrot - the initial motivation for IPv6 was the supposed IPv4 address
shortage. However, that's looking less important than it used to. So, the
future of IPv6 rests on whether any other feature will turn out to be important
enough, or whether people will find some way to use other features to do
something important. Possible "killer applications" are autoconfiguration
for use in embedded systems (for example, light switches), and flow labels
for IP switching.
References
-
[RFC1883]
Internet Protocol, Version 6 (IPv6) Specification. S. Deering & R.
Hinden. December 1995.
-
[RFC791]
Internet Protocol. J. Postel. Sep-01-1981.
-
[IPNG]
IP Next Generation (IPng). Robert Hinden. September 22, 1997.
-
[RFC1819]
Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version
ST2+. L. Delgrossi & L. Berger, Editors. August 1995.
-
[RFC1809]
Using the Flow Label Field in IPv6. C. Partridge. June 1995.
-
[RFC1825]
Security Architecture for the Internet Protocol. R. Atkinson. August 1995.
-
[RFC1826]
IP Authentication Header. R. Atkinson. August 1995.
-
[RFC1827]
IP Encapsulating Security Payload (ESP). R. Atkinson. August 1995.
-
[RFC1885]
IP Version 6 Addressing Architecture. R. Hinden & S. Deering, Editors.
December 1995.
-
[RFC1546]
Host Anycasting Service. C. Partridge, T. Mendez, & W. Milliken. November
1993.
-
[RFC1933]
Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan & E.
Nordmark. April 1996.
-
[RFC1970]
Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark &
W. Simpson. August 1996.
-
[RFC1918]
Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D.
Karrenberg, G. J. de Groot & E. Lear. February 1996.
-
[RFC1971]
IPv6 Stateless Address Autoconfiguration. S. Thomson & T. Narten. August
1996.
-
[IPNGIMPL]
IPng Implementations. Robert Hinden. January 30, 1996.
-
[6BONE]
6bone Home Page. Bob Fink. 22 January 1998.