Article Figure 1 Table 1 Table 2 Table 3 nov2001.tar

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.