tlug: IPv6 Introduction

[Joe Marchak <joem@example.com>]

Thom Garrett of DSR wrote a good introductory article on IPv6 for SysAdmin
magazine.  I thought it might be good to read before the next meeting
since we have an IPv6 talk scheduled, so I got his permission to
circulate the text version of his article, as below.

An interesting quote: 

    "Setting up a separate network may not be feasible for every
     system/network administrator because of your particular environment,
     however, it is highly desirable. I found Linux systems advantageous 
     for this step. I used a Linux system (2.030 kernel) that was sitting
     around the office and downloaded IPv6 software from:
     ftp://ftp.thridwave.net/pub/linux/kernel/IPv6/ "

The article is also available at www.dsrnet.com.

Cheers,

Joe.

Joe Marchak
joem@example.com

-------------------------------------------------------------------------

IPv6 - A Brief Overview       (Copyright: SysAdmin Magazine, Sept. 1998)
Author: Thom Garrett

At the foundation of the Internet and its derivatives (the Web, intranets,
extranets, and Virtual Private Networks) is the definition of the Internet
Protocol (IP). Most administrators of UNIX systems have, at minimum, a
basic understanding of the structure of IP addresses. Additionally, most
are aware of the growth of the Internet and the resulting stress on the
addressing scheme of IPv4, the specification of IP currently employed
around the world. This article concentrates on IP next generation (IPng),
namely IPv6. This article is intended to raise your awareness of IPv6 and
to suggest a possible migration strategy.

IPv6 is designed to address the next generation of products, such as high
performance networks, as well as, perform effectively on networks
operating at lower bandwidths such as hand-held devices. IPv6 does more
than just attack the "depletion of IP addresses" problem. It also
addresses new security features, autoconfiguration capabilities, and
router improvements. The migration to IPv6 has already begun. An
experimental network called the 6bone has been established to test IPv6,
and implementations for IPv6 have already been developed or are currently
being developed on several operating systems and router software. Many
vendors offer beta versions of these products that can be obtained and
tested.

BACKGROUND

The version of IP that we all know is Classic IP or IPv4. IPv4 can handle
232 (4,294,967,296) addresses, assuming perfect allocation. That may seem
like a lot, but when you look at the continuing growth of the Internet
(see www.nw.com/zone/hosts.gif for information) and further inspect the
method of address assignment, you begin to see why it's not such a large
number. As it was initially designed, IPv4 assigns addresses in a very
inefficient way. A vast number of addresses are not even used. For
example, a small organization (needing fewer than 256 unique addresses),
would most likely apply for a Class C address (21-bit net number).
However, an organization that needed slightly more than 256 addresses,
would apply for a Class B address (14-bit net number, 16-bit host number),
which would yield 64,000 possible IP addresses. The largest organizations
are assigned Class A addresses (7-bit net number, 24-bit host number),
yielding approximately 16 million possible addresses.

Thus, an enormous number of assigned IP addresses are definitely
underutilized. Fortunately, a provisional proposal was submitted a few
years back to help address this problem for IPv4. One of the actions taken
was to permit the assignment of Class C addresses in contiguous chunks to
create mini-Class B networks. This divided the potentially unused portions
of large Class C addresses into smaller usable segments.

IPv6 was presented to the Internet Engineering Task Force (IETF) in July,
1994. The recommendation was reviewed and accepted by the Internet
Engineering Steering Group in November, 1994. Then in September, 1995, the
IPv6 protocols were approved and became an IETF Proposed Standard. The
IETF is now committed to IPv6. It realizes that the next generation
products and technologies will probably look toward IP to provide a
structured backbone. Some examples of next generation products are
hand-held devices, applications over NetPCs, and networking for home
entertainment. IPv4 will not be able to handle the products in store for
the future. This market explosion will happen regardless of IPv6, and, if
IPv6 is available and stable, it will be used. Most of the ISPs I spoke
with were aware of the impending growth, but did not yet have a plan for
switching over to IPv6.

I imagine IPv6 addresses will be assigned to providers much in the same
way addresses are assigned now. Most providers should be able to
accommodate both IPv4 and IPv6 traffic in the near future, but it would be
prudent to call your ISP to determine their status on this issue. Also, if
you are looking for a provider for the first time or switching providers,
IPv6 readiness should be one of the factors involved in your decision.
IPv6 will not happen suddenly, destroying your current configuration and
all that you have worked for; however, you should learn about it. You will
probably encounter it in house first, in a controlled environment.
You may be wondering what happened to IPv5. IPv5 was an experimental
protocol known as ST. This protocol was never widely used, in essence,
becoming a footnote.

DIFFERENCES BETWEEN IPv4 and IPv6

IPv4 and IPv6 differ in several ways. The predominant difference is the
simplified header format (see below for details). Some of the other major
differences in IPv6 include the increased network address size (128 bits
compared to the 32 bits in IPv4), the absence of header checksums, the
introduction of flow labels, and the fact that fragmentation information
is an option rather than a requirement for all datagrams.
The simplified header is designed to facilitate efficiency of header
processing software. Software can easily be tailored and optimized around
the 40-byte (fixed-length) IPv6 headers. This contrasts with IPv4 headers,
which are of arbitrary length. Thus, current IPv4-based systems must
process headers of varying length, resulting in considerable processing
overhead. Multi-byte fields have been realigned to be more efficient in
IPv6, and a number of IPv4 fields have been done away with altogether.
When viewing the IPv6 datagram, note that the source and destination
addresses are four times larger that the IPv4 counterpart. Four times
larger is 128 bits, which is equivalent to
340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses.

IPv6 addresses are represented by sixteen 8-bit segments separated by
colons. Those of you who enjoy typing ATM addresses or entering flexlm
licenses for third party software will just love IPv6 addresses. A typical

address might look like the following:

C87E:34CA:BA55:0000:CDE7:92E4:58D1:1729

Fortunately, the developers of IPv6 have provided some conventions to help
those who must work with them. A few addressing conventions are:
If a 16-bit segment contains all zeros, then you can substitute one 0.
If there are consecutive 16-bit segments containing all zeros, then you
can represent it with two colons. However, there can only be one such
two-colon abbreviation in an address.

If a 16-bit segment is less than 0x1000, then the leading zeros are not
necessary.

IPv4 addresses can be represented in IPv6 format by padding 96 bits of
zeros to the front of the IPv4 address. For example, 192.168.168.1 would
be ::192:168:168:1.

IPv6 offers three types of IP addresses: unicast, multicast, and anycast.
Unicast addresses are the simplest type of addresses. If a unicast address
is the destination address, then the network will deliver the message to
that particular interface.

Multicast addresses identify a group of interfaces. There is no broadcast
addressing in IPv6. Broadcast addressing could, however, be accomplished
by using multicast.

Anycast addresses are new with IPv6. An anycast address is an address that
is assigned to a set of interfaces, but only needs to reach at least one
("any of") rather than all interfaces. This differs from multicast, in
which the message must be received by all interfaces of that set.
A new capability introduced with IPv6 enables the labeling of packets
belonging to particular traffic "flows", for which the sender requests
special handling. These are called Flow Labels. The flow label, along with
a source address, identifies a particular traffic flow in the network. An
example of a special request would be a real-time service or a non-default
quality of service (QOS). At the time of this article, the definition of
flow label is still in a state of flux and thus is subject to change.
IPv6 is security conscience and offers improved security features.
Actually, it makes security a mandatory feature of the protocol. IPv6
provides features such as authentication, encryption, and confidentiality,
and specifies the MD5 (Message Digest 5) algorithm as the default
authentication algorithm. It can use many different encryption algorithms.
The default encryption algorithm is DES-CBC (Data Encryption Standard,
Cipher Block Chaining model). It helps support confidentiality by using
ESP (encapsulating security payload).
The IPv4 and IPv6 datagram formats shown in Figures 1 and 2 were taken
from the RFCs. Figure 1 shows the IPv4 format and a brief field
description. Figure 2 shows the IPv6 datagram header format.
 
Figure 1 

IPv4 Internet Datagram Header Format (Internet Protocol Specification
RFC791, Sept. 1981)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address                                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address                                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version: 4 bits 
    The Version field indicates the format of the Internet header.
IHL: 4 bits 
    Internet Header Length is the length of the internet header in 32
bit     words, hence points to the beginning of the data.
Type of Service: 8 bits 
    Provides an indication of the abstract parameters of the quality
of     service desired.
Total Length: 16 bits
    Total Length is the length of the datagram, measured in octets.
Identification: 16 bits
    An identifying value assigned by the sender to aid in assembling
the     fragments of a datagram.
Flags: 3 bits
    Various Control Flags.
Bit 0: reserved, must be zero
Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment.
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
Fragment Offset: 13 bits
    This field indicates where in the datagram this fragment belongs.
Time to Live: 8 bits
    This field indicates the maximum time the datagram is allowed to
remain in     the internet system.
Protocol: 8 bits
    This field indicates the next level protocol used in the data
portion of     the Internet datagram.
Header Checksum: 16 bits
    A checksum on the header only. Since some header fields change
(e.g.,     time to live), this is recomputed and verified at each point
that
the     Internet header is processed.
Source Address: 32 bits 
    The source address.
Destination Address: 32 bits
    The destination address.
Options: variable
    The options may appear or not in datagrams. They must be
implemented by     all IP modules (host and gateways). What is optional is
their     transmission in any particular datagram, not their
implementation.
In some     environments the security option may be required in all
datagrams
Padding: variable
    The Internet header padding is used to ensure that the Internet
header     ends on a 32-bit boundary. The padding is zero.

Figure 2

IPv6 Header Format (RFC 1883, IPv6 Specification, December 1995)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label                                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Source Address                           +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                    Destination Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version: 4-bit Internet Protocol version number = 6.
Prio.: 4-bit priority value.
Flow Labe: 24-bit flow label.
Payload Length: 16-bit unsigned integer. 
    Length of payload (i.e., the rest of the packet following the IPv6
header,     in octets). If zero, indicates that the payload length is
carried in a     Jumbo Payload hop-by-hop option. 
Next Header: 8-bit selector. 
    Identifies the type of header immediately following the IPv6
header. Uses     the same values as the IPv4 Protocol field.
Hop Limit: 8-bit unsigned integer. 
    Decremented by 1 by each node that forwards the packet. The packet
is     discarded if Hop Limit is decremented to zero.
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).
 
MIGRATION EXPECTATIONS

When will the IPv4-based Internet run out of addresses? Some resources
predict anywhere between 2005 and 2020. If nothing were being done about
the situation, it would probably be closer to 2003-2005. However, because
of the efforts of the IETF, the Internet Architecture Board, and others,
IPv6 will already be employed into the current Internet, thereby
alleviating some of the pressure. IPv6 implementers have configured an
experimental backbone to test the IPv6 protocol called the 6bone. Its
fundamental purpose is to facilitate the evolution and deployment of IPv6.
Currently, several systems from different manufacturers are connected to
it, and they are working on various connectivity issues. 
Interoperability between IPv4 and IPv6 is probably one of the most
important objectives for migration. The designers built in several
migration mechanisms to help facilitate the transition process. Note that
IPv4 will not be totally replaced by IPv6 anytime in the near future.
There is an enormous IPv4 base that must be protected; IPv6 developers
recognize this. The following is a suggested migration path and some
mechanisms that may help:

0. Set up a mock network for testing and learning. Setting up a separate
network may not be feasible for every system/network administrator because
of your particular environment, however, it is highly desirable. I found
Linux systems advantageous for this step. I used a Linux system (2.030
kernel) that was sitting around the office and downloaded IPv6 software
from: ftp://ftp.thridwave.net/pub/linux/kernel/IPv6/

1. If a mock network is not set up, the following steps still can be
applied to an existing network.

2. Upgrade DNS server to handle IPv6 - Before nodes can be upgraded to
IPv6, the DNS server must be upgraded to IPv6.

3. Introduce dual stack systems that support IPv4 and IPv6. Update the DNS
records to include these dual stack systems. Nodes and routers can be
introduced to the network one at a time. The entire network does not need
to be upgraded at the same time. When IPv4 nodes are upgraded, they can
continue to use their current addresses.
 
4. Take advantage of the automatic tunneling feature to connect IPv6
segments separated by IPv4 segments. There may be situations when IPv4
compatible addresses are not available, thus automatic tunneling will not
work. In these cases, configured tunneling can be used. This requires
explicit configuration at the IPv4 entry point and is more work, but does
offer a solution.
 
5. Use the header translation mechanism to reach IPv4-only nodes. By
providing a way to convert the older addresses to and from the new format,
IPv6 can communicate directly with IPv4 hosts. This will protect the huge
investment currently seen in IPv4 networks.
 
CONCLUSION

IPv6 is an essential part of the next generation Internet. IPv6
implementation efforts are underway by many vendors. The designers are
aware of its implications and have done well in communicating them to the
ITEF. Several ISPs are actively participating in the upgrade process and
are involved with testing 6bone. System and network administrators should
become familiar with IPv6 as soon as possible and learn how it differs
from IPv4. The more you know about the subject, the better equipped you
are to assess and manage it.

Additional Resources

RFCs
http://ds.internic.net/rfc/rfc791.txt - IPv4 Specification
http://ds.internic.net/rfc/rfc1883.txt - IPv6 Specification
http://ds.internic.net/rfc/rfc1884.txt - IPv6 Addressing Architecture
http://ds.internic..net/rfc/rfc1886.txt - DNS Extensions to Support 
IPv6

http://ds.internic.net/rfc/rfc1933.txt - Transition Mechanisms for 
IPv6 Hosts & Routers

http://ds.internic.net/rfc/rfc1971.txt - IPv6 Stateless Address 
Autoconfiguration

http://ds.internic.net/rfc/rfc1972.txt - A Method For The 
Transmission of IPv6 Packets Over Ethernet Networks
Informative Web sites:

http://playground.sun.com/pub/ipng/html/ipng-main.html - 
A good IPv6 Resource Page 

www.ietf.org/html.charters/ipngwg-charter.html - IPng Working 
Group Charter

www.visc.vt.edu/ipv6 - Virginia Tech IPv6 Testbed
www.6bone.net - 6Bone Home Page

http://docs.bit.ternopil.ua/Incoming/FAQ/IPv6/ \
linux-ipv6.faq-5.html - Linux Reference

Mailing Lists

IPng working group - Send email to: majordomo@example.com with
"subscribe ipng" in the body portion of the message. An archive can be
found in the IETF directories at: cnri.reston.va.us.
6Bone Mailing List - Send email to: majordomo@example.com with "subscribe
6bone" in the body portion of the message.

Books
IPng, Internet Protocol Next Generation by Scott O. Bradner,
Addison-Wesley.
IPng and the TCP/IP Protocols, Implementing the Next Generation Internet
By Stephen A. Thomas, John Wiley & Sons, ISBN: 0471130885.
Some vendors and organizations that have begun IPv6 development:
DEC        3Com        IBM
Silicon    Graphics    Bay Networks
Siemens    SUN        Novell
CISCO        Linux        NRL
Hitachi    Telebit    Ipsilon Networks
UUnet        Apple        Microsoft
AT&T        NIST        NASA 
 
Author Bio:

Thom Garrett has been involved in various aspects of system/network
installation and administration for 12 years. He received a B.S. in
Mathematics/Computer Science from Virginia Commonwealth University. He is
currently employed at Digital System Resources, Inc located in Fairfax,
Virginia, where he is Manager of Computer Services. He can be reached at:
tgarrett@example.com
 

+-- Thom Garrett -----------------;^)%--------------------------------+
    DSR(r) - Manager, Computer Services     
    (703) 263.2841 - Office             "LOVE: Complex Yet Simple" -trg
    (703) 626.3606 - Mobile                      
+-- tgarrett@example.com --- www.dsrnet.com ---------------------------+



---------------------------------------------------------------
Next Meeting: 10 October, 12:30 Tokyo Station Yaesu central gate
Next Nomikai: 20 November, 19:30  Tengu TokyoEkiMae 03-3275-3691
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp