I have a netscreen SSG firewall from which I wanted to establish a tunnel to SixXS. I tried this in the past when IPv6 support had just been added, but didn't have much luck. However, nowadays it works pretty well. I've had a working tunnel for about a year now.

The first thing to do is to get a tunnel to an IPv6 broker and request a subnet for your internal systems. Personally I use SixXS but you can probably use any broker you like. As an example, I'll be using these settings:

• Tunnel broker ipv4 address: 127.34.8.97
• Tunnel ipv6 address: 2001:DB8:202:123::2/64
• ipv6 subnet used internally: 2001:DB8:8AA:1::/64

Second, start by upgrading your device to the latest available firmware. IPv6 support is constantly improving as support for more ALGs is added. If you still have a 5GT, you're stuck using 5.4 but if you have an SSG, you can upgrade to 6.0 or even 6.1.

Next, enable IPv6 support on the device. It's not enabled by default so you have to change a boot parameter and restart the device. You can only do this from the CLI:

set envar ipv6=yes

After the device has rebooted, you'll see that there are a few new commands available to configure IPv6 on interfaces and use IPv6 addresses in policies. Next we'll begin configuring the tunnel to our tunnel broker. I'd recommend doing this from the CLI when you are using version 5.4 because the WebUI had some bugs back then.

set interface tunnel.1 zone "Untrust"
set interface tunnel.1 ipv6 mode "host"
set interface tunnel.1 ipv6 ip 2001:DB8:202:123::2/64
set interface tunnel.1 ipv6 enable
set interface tunnel.1 tunnel encap ip6in4 manual
set interface tunnel.1 tunnel local-if adsl2/0 dst-ip 127.34.8.97
set interface tunnel.1 mtu 1280
set route ::/0 interface tunnel.1 gateway :: preference 20

This should give you a working tunnel and allow you to ping IPv6 addresses from the netscreen itself. Next we'll assign an IPv6 address to our internal interface and configure it so that the attached systems will get an autoconfigured address:

set interface ethernet0/1 ipv6 mode "router"
set interface ethernet0/1 ipv6 ip 2001:DB8:8AA:1::1/64
set interface ethernet0/1 ipv6 enable
unset interface ethernet0/1 ipv6 ra link-address
set interface ethernet0/1 ipv6 ra transmit
set interface ethernet0/1 ipv6 nd nud

That should give your internal systems an IPv6 address. All that is left now is configure a policy to allow the IPv6 traffic to pass through. Configuring this is just like when you are using IPv4, except that there now isn't an object named "Any" anymore but there are two, "Any-IPv4" and "Any-IPv6".
A simple policy to allow outbound connections would be:

set policy from "Trust" to "Untrust" "Any-IPv6" "Any-IPv6" "ANY" permit log

Of course, I'd recommend to make them a bit more restrictive. Be very careful with rules from Untrust to Trust. All your internal systems will have a public IP address, don't just allow everything or you might wake up one morning and find something like this:

One thing to keep in mind when you are updating your policies is that you cannot have both IPv4 and IPv6 addresses in one address group. This effectively means that you will have separate policies in your rulebase for IPv4 and IPv6, so try to keep them ordered logically.

Update sept 13, 2009
I recently set up another IPv6 tunnel, this time on a netscreen 5GT running ScreenOS 6.2r3. I decided to incorporate some of the feedback from the comments below, so that the netscreen can be pinged by SixXS for monitoring. The netscreen should respond to pings on its tunnel interface, but doesn't do so for IPv6 traffic, a bug which has been reported to Juniper but which has not yet been fixed.

So instead of putting my IPv6 endpoint address on the tunnel interface, I used a loopback interface, with a /128 subnet mask. Then I created the tunnel interface as before, but making it unnumbered, inheriting the address from the loopback interface:

set interface "loopback.1" zone "Untrust"
set interface "loopback.1" ipv6 mode "host"
set interface "loopback.1" ipv6 ip 2001:DB8:202:123::2/128
set interface "loopback.1" ipv6 enable
set interface loopback.1 route
set interface loopback.1 manage ping
unset interface loopback.1 ipv6 nd nud
 
set interface tunnel.6 ip unnumbered interface loopback.1
set interface "tunnel.6" ipv6 mode "host"
set interface "tunnel.6" ipv6 enable
set interface tunnel.6 tunnel encap ip6in4 manual
set interface tunnel.6 tunnel local-if adsl2/0 dst-ip 127.34.8.97
set interface tunnel.6 mtu 1280
! had to disable NUD otherwise the tunnel interface state changed to down.
unset interface tunnel.6 ipv6 nd nud
 
set route ::/0 interface tunnel.6 gateway :: preference 20
 
! note: an explicit policy is only needed when intra-zone blocking is enabled on the Untrust zone
set policy name "SixXS monitoring" from "Untrust" to "Untrust"  "Any-IPv6" "2001:DB8:202:123::2/128" "ICMP6 Echo Request" permit

This works perfectly. Because my external interface IP is dynamic on this device, I set the SixXS tunnel type to Heartbeat and installed AICCU on an internal machine to keep the connection alive.

Many TLDs already have IPv6 DNS servers, even Belgium has one (brussels.ns.dns.be). Several of the root servers already have IPv6 addresses as well but until now, the root hints file and priming responses served by the root servers only contained the IPv4 records. This will change on Februari 4th when AAAA records are added for 4 of the root servers.

For most people this change will go unnoticed. There is a report that lists the possible issues. The most likely problem is that with the addition of the IPv6 records, the DNS response will be larger than the 512 bytes originally allowed by DNS.

Problems are only to be expected for people running ancient software versions on their DNS resolvers or firewalls (eg old PIX versions). If in doubt, the ICANN website has a list of firewalls that have been tested. That page also has instructions on how to test your firewall. Note that they are testing the hk servers which no longer seem to return such long responses, so you'll need to find another server that does. I used one of the root servers from the Open Root Server Network for testing.

One advantage of ipv6 people seem to be forgetting; everyone is is finally going to have to register everything properly in dns because nobody can remember those long ip addresses ;)