Configuring an OpenSolaris 6to4 router

A common problem in enterprise networks is that many IT departments have not begun to deploy IPv6 within their supported infrastructure, but developers need IPv6 networking in order to develop and test products which support IPv6.  6to4 (defined in RFC 3056) can be a quick way to obtain IPv6 connectivity between IPv6 nodes separated by IPv4 networks such as this.  The general idea is that each 6to4 site has a 6to4 router which is responsible for automatically tunneling IPv6 packets from its site to other 6to4 routers in other 6to4 sites (or native IPv6 networks with the use of relay routers^[1]) over IPv4.  6to4, then, can often be the answer for such developers, where configuring a 6to4 router in a lab environment or in a small subnet within an enterprise network is very easy and addresses their basic IPv6 connectivity requirements.

OpenSolaris^[2] can be used as a 6to4 router, and I've received so many requests for basic instructions on how to configure a 6to4 router with OpenSolaris, that I've decided to write a short blog entry on the subject.  Note that while this blog may come in handy, there is in fact official Sun documentation on 6to4 routing ^[3] which may be even more useful.

The following instructions configure a persistent configuration which will be enabled after a reboot of the system.  All of this can also be configured similarly on the running system, but it is simpler to give one set of instructions.  Experienced administrators will surely know how to interpret these instructions to apply configuration to the running system, and that's left as an exercise to the reader.

1. Enable IPv6 on one of the physical interfaces of the 6to4 router:
   

   touch /etc/hostname6.<intf>

   Where <intf> is the interface in question (e.g., e1000g0).
   
   
2. Configure a 6to4 tunneling interface on the 6to4 router:
   

   echo "tsrc <v4addr> up" > /etc/hostname6.ip.6to4tun0

   Where <v4addr> is the IPv4 address of the 6to4 router.
   
   
3. Enable IPv6 forwarding on the 6to4 router:
   

   routeadm -e ipv6-forwarding

   
   
4. Reboot the system.  When the system comes back up, it will have an IPv6 interface name ip.6to4tun0 which will have an address like 2002:<hex-v4addr>::1 ^[4].  The "2002:<hex-v4addr>::" part is the 48-bit 6to4 site-prefix for your 6to4 site.  All IPv6 nodes in the site that use this 6to4 router must share this common prefix, although it needs to be further sub-divided within each IPv6 subnet in the site in order to be useful (that's what the remaining 16 bits of the /64 prefix are for).  For example, if the site consists of a single IPv6 subnet, then it's easy enough to create a single "2002:<hex-v4addr>:1::/64" prefix by following the following remaining steps.
   
   
5. Enable IPv6 router advertisements on the 6to4 router so that IPv6 hosts on the subnet automatically configure their IPv6 addresses and use this router as their default router:
   

   cat << EOF > /etc/inet/ndpd.conf
   ifdefault AdvSendAdvertisements 1
   prefix 2002:<hex-v4addr>:1::/64 <intf>
   EOF
   

   Where <hex-v4addr> is the same as the <hex-v4addr> displayed in step 4, and <intf> is the physical interface attached to the IPv6 subnet in question.  The ":1" following <hex-v4addr> is important, as this is the 16-bit subnet-id for the prefix being advertised.  It uniquely identifies this /64 prefix from other prefixes in the site, which all share a common /48.  The subnet-id must be non-zero (because the 0 subnet-id was allocated to the 6to4 router's ip.6to4tun0 interface) and unique within the site, so it doesn't necessarily need to be "1".
   
   If the 6to4 router is attached to more than one subnet, then there would be additional "prefix" entries in the ndpd.conf file above, one for each interface.  Each prefix would then have its own unique 16-bit subnet id.
   
   
6. Restart the neighbor discovery daemon for the changes to take effect.
   

   svcadm restart routing/ndp

At this point, hosts which have IPv6 enabled in the link connected to the 6to4 router's <intf> interface will automatically configure IPv6 addresses based on the advertised prefix, and will have a default route to the 6to4 router.  All packets destined off-link to other 6to4 sites will be tunneled to the remote 6to4 routers.

<shameless plug>Of course, when the Clearview IP Tunneling Device Driver component delivers to Nevada, one will be able to use dladm(1M) to create a 6to4 tunnel with a meaningful name, and to observe packets in the 6to4 tunnel using snoop(1M), wireshark, or other such tools.</shameless plug>

[1] I'm skipping discussing relay routers for various reasons which I won't go into here.

[2] In fact, Solaris starting with Solaris 9.

[3] Look for 6to4.  Within this documentation, there are also instructions on how to configure 6to4 on Solaris, similar to this blog entry.

[4] The 2002::/16 prefix is the "magic" 6to4 prefix that allows 6to4 routers to tunnel to one another.  The 32 bits that follow these initial 16 bits is an IPv4 address.  It is the IPv4 address of the 6to4 router which is responsible for the automatic IPv6 tunneling of packets for its 6to4 site.  For example, when a 6to4 router needs to tunnel an IPv6 packet with a destination of 2002:0a01:0203:1::1, it will know to automatically encapsulate this IPv6 packet in an IPv4 header with a destination of 10.1.2.3 (the IPv4 address of the remote 6to4 router).

Posted at 01:01PM Mar 28, 2008 by seb in OpenSolaris  |