 Getting
on the 6bone Quickly with SolarisTM 8
David LaPorte and Kevin Amorin
For those who live on the cutting edge, implementing a new technology
is as much about the "how" as the "why". Gaining
experience with the technologies of tomorrow provides skills and
familiarity that will give you an advantage over the competition.
IPv6 is one such technology. In this article, we will describe some
of the benefits of IPv6, as well as provide a step-by-step method
to get a workstation on the 6bone, the IPv6 test bed. Although many
of the procedures described here can be used to set up a tunnel
with any IPv6 tunnel broker, we focus on Freenet6 (http://www.freenet6.net),
a free service provided by Viagénie Inc. As of this writing,
version 2 of their client software was unavailable for Solaris --
we will instead describe the process of getting a Solaris 8 system
online using version 1.
IPv6 Background
IPv6 is a next-generation protocol destined to replace (or co-exist
with) the current Internet standard, IPv4. IPv6 addresses several
of the problems that are apparent in IPv4.
Address Exhaustion
Over the past several years, the rapid pace of Internet expansion
has exposed some serious weaknesses in its underlying protocol,
IPv4. The most obvious weakness is the size of the address space.
When the specifications for IPv4 were drawn up, the size of an address
was set at 32 bits. This allowed for 232 (4,294,967,295) addresses
and was thought to be more than sufficient. To make matters worse,
an inefficient allocation system was used to distribute addresses.
Depending on the stature and size of an organization, a particular
class of network was assigned. These classes seldom fit an organization's
size, and larger networks than necessary were often allocated. Table
1 lists the different classes.
In 1990, it was forecast that the class B address space would
be exhausted by 1994. Clearly, something needed to be done. In 1993,
RFC-1519 was published. It detailed a system called Classless Inter-Domain
Routing (CIDR) that allowed for the use of a network prefix. Unlike
traditional subnet masks that "broke" an address on octet
boundaries, a network prefix could consist of any number of bits.
The goal of CIDR was two-fold: to reduce the inefficiency in address
allocation and to slow the growth of Internet routing tables. Until
CIDR was implemented across the Internet in 1994, the assignment
of addresses was fairly arbitrary. Contiguous networks could be
assigned to different organizations, each being logically or geographically
distant. As such, most networks would require their own entry in
the Internet routing table. When CIDR was implemented, blocks of
contiguous networks were allocated to service providers, which in
turn were allocated to customers. Since the networks shared a common
prefix, a single, more general route could be added to the routing
table. CIDR slowed the growth of Internet routing tables and postponed
the exhaustion of address space, but a more permanent solution was
still necessary. The Internet routing table is now approximately
100,000 entries and climbing, and the IP address space is still
due to be exhausted by 2010.
Many companies, trying to conserve the addresses they use, have
implemented Network Address Translators (NATs -- detailed in
RFC-3027). These systems allow many machines to use private addressing
(defined in RFC-1918) and share a single public IP address. While
these systems work for many applications, they often break the functionality
of complex protocols like H.323 or IPSec. Additionally, NATs break
the "end-to-end" model that the Internet was built upon.
While NATs work, and work well for many organizations, they cannot
serve as the foundation for future expansion.
IPv6 provides a more permanent solution to the problems addressed
by CIDR. The address length has been increased from 32 bits to 128
bits. While IPv4 allowed for a maximum of approximately four billion
nodes, the IPv6 address space allows for more than 2128 nodes --
about 1023 addresses per square meter of the Earth's surface.
Also, the allocation of IPv6 addresses will be more hierarchical,
helping to reduce the size of Internet routing tables.
Table 2 shows the fields that make up the 128-bit IPv6 address.
FP -- Format Prefix (unicast, multicast, anycast, etc.)
TLA ID -- Top-Level Aggregation Identifier
RES -- Reserved for future use
NLA ID -- Next-Level Aggregation Identifier
SLA ID -- Site-Level Aggregation Identifier
INTERFACE ID -- Interface Identifier
At the root of the hierarchy sit the top-level aggregators. At
present, there are only three TLA allocations:
2001::/16 -- Early production allocations
2002::/16 -- 6to4 prefix
3FFE::/16 -- Test Address Space for the 6bone
As the use of IPv6 spreads, the number of TLAs will increase to
encompass large transit providers and exchanges.
Next in the hierarchy are the next-level aggregators (NLAs). An
NLA, such as, a regional ISP, receives an allocation from a TLA.
It, in turn, allocates addresses from its space to its customers,
the SLAs. It should be noted that this is a relatively simple example;
the NLA ID field can be split to accommodate hierarchical allocations
to multiple NLAs. The SLA has about 65,535 subnets that can be used,
each containing a possible 264 nodes. Networks of this size are
not anticipated; the 64-bit interface identifier is to be used for
autoconfiguration (described below)
Security
IPv4 is vulnerable to various forms of spoofing and sniffing attacks
because it lacks encryption and authentication. The security and
encryption mechanisms you may be familiar with, such as SSH, SSL,
or PGP, work above the network layer of the protocol stack, where
IP operates. The number and variety of these techniques are confusing
for the end user and often require redundant configuration.
IPv6 provides security without the higher level application needing
to be aware of it. Spoofing and man-in-the-middle attacks are defeated
using the optional Authentication Header (AH). The AH provides a
method to guarantee that who you are talking to is who you think
you're talking to. More passive attacks, like sniffing, can
be foiled using the IPv6's Encapsulating Security Payload (ESP)
service.
Mobility
Until recently, most nodes on the Internet were hardwired systems,
most likely sitting in a server room or on someone's desk.
As technologies like 802.11b and 3G take off, the demand for address
space and need for mobility will increase. Unlike IPv4, IPv6 was
designed to provide a means of moving between networks while maintaining
your address. Although Mobile IP is available under IPv4 (defined
in RFC-2002), it is not a protocol requirement like it is under
IPv6.
Ease of Configuration
An IPv6 node can automatically configure its own address by using
the Neighbor Discovery Protocol (NDP). In addition to a globally
unique address, an IPv6 node also has site-local and link-local
addresses. As the names imply, each is unique only within a certain
domain -- a single network or single organization. A link-local
address has a prefix of fe80::/64 and the node's interface
ID as the remainder. On an Ethernet, an EUI-64 address consists
of a hardware address with the hex bits "FFFE" inserted
in the middle, and the interface ID is simply the EUI-64 address
with the second to lowest order bit of the first byte complemented.
For instance, a node with a hardware address of 08:00:20:83:43:42
would have an EUI-64 address of 08:00:20:FF:FE:83:43:42 and a link-local
address of fe80::a00:2083:4342.
The node sends out a Neighbor Solicitation message with its link-local
address as the source. If another host responds, meaning that the
address is already in use, the interface must be manually configured
with a different link-local address. Otherwise, the node sends a
Neighbor Discovery message using a defined multicast address with
its link-local address as the source. Routers on the link respond
with the network prefix used on the subnet. The node then concatenates
the prefix with its interface ID to generate a globally unique address.
This is very useful when large groups of systems need to be migrated
to a new address space, as the prefix advertised by the router can
easily be changed. This also makes it much easier for novice users
to get online. If more control over address allocation is needed,
DHCP will still be supported under IPv6.
The 6bone
The 6bone is an IPv6 testbed that has been assigned the TLA ID
3FFE::/16. Networks are in turn allocated to pseudo-TLAs. Although
the 6bone mainly comprises IPv6 "islands" connected by
tunnels over the existing IPv4 infrastructure, IPv6-only links are
slowly coming online. For more information about the 6bone, visit:
http://www.6bone.net
There are several ways to connect to the 6bone. As an end user, you
are not likely to get a "native" IPv6 connection from your
ISP (most service providers have yet to offer IPv6 connectivity).
Your two main choices, therefore, are 6to4 or an IPv6 tunnel --
both of which work by encapsulating IPv6 packets in IPv4 and shuttling
them across the Internet. 6to4 has been allocated a TLA ID of 2002::/16
and works by "embedding" your IPv4 gateway address in the
IPv6 address. For instance, if my IPv4 gateway address were 64.220.244.244
(which is 40.DC.F4.F4 in hex), my IPv6 prefix would be 2002:40DC:F4F4/48.
You can then use the remaining 80 bits of address space in any way
you choose. For instance, you could divide it into 65,535 networks
as follows:
2002:40DC:F4F4:0000::/64
2202:40DC:F4F4:0001::/64
2202:40DC:F4F4:0002::/64
...
2202:40DC:F4F4:FFFD::/64
2202:40DC:F4F4:FFFE::/64
2202:40DC:F4F4:FFFF::/64
If you'd like to interconnect with the 6bone, as well as
other 6to4 sites, you must point your 6to4 traffic at a relay router.
A list of available 6to4 relay routers can be found at:
http://www.kfu.com/~nsayer/6to4/
Freenet6 uses an IPv6 tunnel to connect your site to the 6bone. As
of this writing, it is not yet possible to route a network through
the tunnel -- you are limited to only one node. Figure 1 shows
how a tunnel works.
The tunnel you establish with your tunnel broker (Freenet6, in
this case) is carried over the public Internet. Before leaving your
tunnel interface, IPv6 traffic is encapsulated in IPv4 packets.
Once it reaches the broker, the IPv4 headers are stripped off and
the resulting IPv6 packets are sent out onto the 6bone. Although
we reference Freenet6, there are many public tunnel brokers available.
For a listing, visit:
http://hs247.com
Configuring Solaris
Although we reference Solaris 8 specifically, the following procedure
should also apply to Solaris 7 FCS (First Customer Shipment) with
experimental IPv6 patches. For more information on IPv6 support
for Solaris 7, visit:
http://playground.sun.com/pub/solaris2-ipv6/html/solaris2-ipv6.html.
Solaris 8 has native support for IPv6, and implements a dual stack
model. A dual stack node can interoperate with both IPv4 and IPv6
nodes. It also provides resolver libraries capable of dealing with
the IPv4 A records as well as the IPv6 equivalents. And because a
dual stack machine can be on both networks simultaneously, the dual
stack model eases the transition to IPv6.
During the Solaris 8 installation, you will be prompted to enable
IPv6 support. If selected, you will notice an IPv6 loopback interface
(::1) and an IPv6 interface with your local-link address on boot-up.
Below is a typical output after enabling IPv6:
#ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232
index 1 inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
index 2 inet 64.220.244.244 netmask ffffff00 broadcast 64.220.244.255
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252
index 1 inet6 ::1/128 lo0:
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:fec5:308d/10
If you did not enable IPv6 support during installation, don't
fret -- you can enable IPv6 support by creating the file /etc/hostname6.<interface>,
where <interface> is any existing interface for which
you would like to enable IPv6 (e.g., hme0, le0, qfe0, eri0). You will
then need to either reboot the system or restart /etc/init.d/network.
IPv6 configuration files are very similar to their IPv4 counterparts.
Table 3 shows the appropriate Solaris configuration files based
on IP version.
The /etc/inet/ipnodes file is the IPv6 equivalent of the
/etc/hosts file and each file shares the same format. The
hostname6.<interface> file provides similar functionality
for IPv6 interfaces as hostname.<interface> provides
for IPv4. Creating an empty hostname6.<interface> file,
however, will force Solaris to automatically generate an IPv6 logical-link
address. The /etc/nsswitch.conf file in Solaris 8 has an
additional entry -- ipnodes. This entry allows you to configure
name resolution order for IPv6 queries. A typical entry in /etc/nsswitch.conf
is:
ipnodes: files dns nis
This entry will make the system look to /etc/inet/ipnodes,
DNS, and finally to the NIS ipnodes table for name resolution.
Configuring Solaris to Use Freenet6
We will now show how to use the native Solaris 8 IPv6 support
to access the Freenet6 IPv6 tunnel broker. Freenet6, as described
above, is a free IPv6 tunnel broker connected to the 6bone, an IPv6
testbed. In addition to Solaris 8, Freenet6 also provides support
for *BSD, NT, Cisco, and Linux.
The first step is to visit the Freenet6 Web site and register
your tunnel at:
http://old.freenet6.net/en/createTunnel.html
After registration, you will be given a slew of information and a
script to execute that will configure your system to connect to the
Freenet6 server. Be sure to note your IPv4 address, the generated
IPv6 address, and the tunnel broker's IPv4 and IPv6 addresses
from the registration output. The following describes the operations
of the Freenet6 Solaris 8 tunnel configuration script:
1. Touch /etc/hostname6.<interface> -- Where
<interface> is any existing interface for which you would
like to enable IPv6 (e.g., hme0, le0, qfe0, eri0). After reboot,
IPv6 will be enabled on the interface, and a link-local address
automatically will be generated and assigned.
2. Create /etc/hostname6.ip.tun0 and add the following
lines:
tsrc <Your IPv4 address> tdst <Tunnel server's IPv4 Address>
addif <Your IPv6 address> <Tunnel server's IPv6 address> up
This step will create the IPv6 tunnel interface and bind it to Freenet6.
3. Append to /etc/init.d/inetinit the line:
/usr/sbin/route add -net6 default <Tunnel server's IPv6 address>
Step 3 adds an IPv6 default route within /etc/init.d/inetinit.
The functionality of /etc/defaultrouter for IPv6 is not supported
in Solaris so a route statement must be added to /etc/init.d/inetinit.
The Solaris neighborhood discovery daemon (in.ndpd) may be
able to find and add the IPv6 default route dynamically, but this
will ensure that the route is added. This step is not implemented
in the Freenet6 script, but is highly recommended, because the default
route will be lost after a reboot.
4. Reboot your system -- If your system cannot be rebooted,
restart network initializing scripts /etc/init.d/network
and /etc/init.d/inetinit.
Testing
Once you have restarted your system, check whether the tunnel
has been added. A simple ifconfig should show the ip.tun0
interface present:
#ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232
index 1 inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
index 2 inet 64.220.244.244 netmask ffffff00 broadcast 64.220.244.255
lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252
index 1 inet6 ::1/128
hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 fe80::a00:20ff:fec5:308d/10
ip.tun0: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6>
mtu 1480 index 4
inet tunnel src 64.220.244.244 tunnel dst 206.123.31.102
inet6 fe80::185b:dced/10 --> fe80::ce7b:1f66
ip.tun0:1: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6>
mtu 1480 index 4
inet6 3ffe:b00:c18:1fff::8bb/128 --> 3ffe:b00:c18:1fff::8ba
The next big hurdle is the routing. IPv6 has a separate routing table
in the dual stack implementation, as shown below in the netstat
output. Make sure the IPv6 default route is entered and is pointing
to your tunnel broker's IPv6 address:
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
64.220.244.244 64.220.244.1 U 1 2 hme0
224.0.0.0 64.220.244.1 U 1 0 hme0
default 64.220.244.1 UG 1 104
127.0.0.1 127.0.0.1 UH 15 1175 lo0
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
------------------------ ------------------------- ----- --- ------ -----
fe80::ce7b:1f66 fe80::185b:dced UH 1 0 ip.tun0
3ffe:b00:c18:1fff::8ba 3ffe:b00:c18:1fff::8bb UH 1 1 ip.tun0:1
fe80::/10 fe80::a00:20ff:fec5:308d U 1 0 hme1
fe80::/10 fe80::a00:20ff:fec5:308d U 1 0 hme0
ff00::/8 fe80::a00:20ff:fec5:308d U 1 0 hme0
default 3ffe:b00:c18:1fff::8ba UG 1 1
::1 ::1 UH 1 0 lo0
Now that your interface is up and your routes are first-rate, it's
time to test the tunnel. Ping the tunnel broker's IPv6 address;
this should also be your IPv6 default route:
# ping -Ainet6 3ffe:b00:c18:1fff::8ba
3ffe:b00:c18:1fff::8ba is alive
Finally, check whether you can ping a host on the 6bone:
# ping -Ainet6 -s www.6bone.net
PING www.6bone.net: 56 data bytes
64 bytes from www.6bone.net (3ffe:b00:c18:1::10): icmp_seq=0. time=133. ms
64 bytes from www.6bone.net (3ffe:b00:c18:1::10): icmp_seq=1. time=114. ms
64 bytes from www.6bone.net (3ffe:b00:c18:1::10): icmp_seq=2. time=137. ms
Doing Something Useful
So, you're up and pinging on the 6bone -- what do you
do now? Many daemons come IPv6-enabled out of the box while others
require a source code patch. Below is a list of several popular
daemons and the status of IPv6 support in each:
BIND -- Supported in BIND9
Apache -- Requires source code patch
Sendmail -- Supported as of version 8.10
Qmail -- Requires source code patch
SSH -- Supported
OpenSSH -- Supported
tcp_wrappers -- IPv6-enabled version available
Source code patches for many utility daemons are available at
the KAME project patch repository:
ftp://ftp.kame.net/pub/kame/misc/
Conclusion
Although there isn't a whole lot to do once you're there,
getting on the 6bone will give you a glimpse of the future as well
as valuable experience. IPv6 promises to make life easier for network
administrators and end users alike through autoconfiguration, as
well as facilitate wireless deployments through its security and
mobility features. Although IPv4 will remain part of the Internet
landscape for years to come, IPv6 is making inroads and will inevitably
play a larger role in every sys admin's life.
References
IPv6 Information -- http://hs247.com/
Overview of the introduction of IPv6 in the Internet -- http://www.ietf.org/proceedings/00jul/I-D/ngtrans-introduction-F1-04.txt
Nick's list of public 6to4 relay routers -- http://www.kfu.com/~nsayer/6to4/
IPng Implementations -- http://playground.sun.com/pub/ipng/html/ipng-implementations.html
Introduction to IPv6 -- http://www.onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html?page=1
Freenet6 -- http://www.freenet6.net IPv6 prototype
for Solaris 7
FCS -- http://playground.sun.com/pub/solaris2-ipv6/html/solaris2-ipv6.html
IPv6 Testing Address Allocation (RFC-2471) -- http://www.ietf.org/rfc/rfc2471.txt?number=2471
An IPv6 Aggregatable Global Unicast Address Format (RFC-2374)
--http://www.ietf.org/rfc/rfc2374.txt?number=2374
The technical case for IPv6 -- http://www.stardust.com/ipv6/documents/v6tech.htm
Guidelines for 64-bit Global Identifier (EUI-64(tm)) Registration
Authority -- http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
Kevin Amorin (kevin@amorin.org) and David LaPorte
(dave@laportestyle.org) are both employed by Harvard
University and are partners in NEPD, a Boston-based consultancy.
| 
