IPv6 at home or office, part 4.1: 6in4 tunnel on Juniper ScreenOS firewall

This blog post is part of a series on ipv6. Part 4.0 describes requesting a Hurricane Electric tunnel; this part explains how to configure a Juniper ScreenOS firewall – SSG, ISG or Netscreen – to work with such a tunnel.

Sample environment

I am going to give an example based on ScreenOS 6.0.0 or later syntax. ScreenOS 5.4 is reported to support IPv6 6in4 tunnels, as well, though it does not expose the configuration to the web interface.

These settings can (almost) all be configured through the web interface. In the interest of brevity, I am going to show CLI commands instead.

Here are the interface names and addresses used in this example. In this example, I use the IPv6 documentation prefix. When configuring this, you get the real addresses from the Tunnel Details page.

External interface name: ethernet0/0, Untrust zone

Internal interface name: bgroup0, Trust zone

Tunnel interface name: tunnel.1, Untrust zone

Server IPv4 address:

Server IPv6 address: 2001:0db8:1:223::1/64

Client IPv6 address: 2001:0db8:1:223::2/64

Routed /64: 2001:0db8:2:223::/64

Anycasted IPv6 Caching Nameserver: 2001:0db8:1234::2

Enabling IPv6

This is the one step you must do from command line. Enter:

set envar ipv6=yes

and reboot. This will enable IPv6 features on your ScreenOS device.

Setting up the tunnel

The first step is to set up a tunnel interface that will allow you to encapsulate IPv6 packets in IPv4 packets.

set interface “tunnel.1” zone “Untrust”
set interface “tunnel.1” ipv6 mode “host”
set interface “tunnel.1” ipv6 ip <Client IPv6 address>
set interface “tunnel.1” ipv6 enable
set interface tunnel.1 tunnel encap ip6in4 manual
set interface tunnel.1 tunnel local-if <External interface> dst-ip <Server IPv4 address>
set interface tunnel.1 mtu 1480
unset interface tunnel.1 ipv6 nd nud
set interface tunnel.1 ipv6 nd dad-count 0
set route ::/0 interface tunnel.1 gateway <Server IPv6 address>

We’re creating the tunnel.1 interface, assign it to the “Untrust” zone, and give it its IP address, the “Client IPv6 address”.

Next we’re creating the tunnel itself, terminating on the external interface on one side and the Server IPv4 address on the other side.

We restrict MTU to 1480 as that is the largest packet that can go through without fragmentation, and disable Neighbor Unreachable Detection for good measure. I haven’t had issues with nud on, but others have.

Finally, create a default IPv6 route through the tunnel.1 interface, so our IPv6 traffic has somewhere to go.

Setting up IPv6 for the local network

Next, we’ll use the “Routed /64” that HE gave us for our internal network.

set interface “bgroup0” ipv6 mode “router”
set interface “bgroup0” ipv6 ip 2001:0db8:2:223::1/64
set interface “bgroup0” ipv6 enable
unset interface bgroup0 ipv6 ra link-address
set interface bgroup0 ipv6 ra preference high
set interface bgroup0 ipv6 ra other
set interface bgroup0 ipv6 ra transmit
set interface bgroup0 ipv6 nd nud
set interface bgroup0 ipv6 nd dad-count 0
set interface bgroup0 dhcp6 server
set interface bgroup0 dhcp6 server options dns dns1 <HE IPv6 Name Server>
set interface bgroup0 dhcp6 server enable

Here, we are giving the LAN interface an IPv6 address from the “Routed /64” range – in the interest of simplicity, I chose “1”. We then enable Router Advertisement so that local machines can receive IPv6 addresses from this interface.

We’re also setting the RA “other” bit and enabling DHCPv6 to give out HE’s IPv6 DNS server. Those two steps are optional: It’ll mean that Google’s IPv6-enabled services will resolve with both an IPv4 and an IPv6 address – otherwise, Google will only be reachable by IPv4.

Setting up an IPv6 firewall policy

As an example, here is a very simple policy that allows all outgoing IPv6 traffic, and denies all incoming IPv6 traffic. Adjust as fits your environment.

set policy from “Trust” to “Untrust”  “Any-IPv6” “Any-IPv6” “ANY” permit
set policy from “Untrust” to “Trust”  “Any-IPv6” “Any-IPv6” “ANY” deny


IPv6 at home or office, part 4.0: tunnelbroker.net, IPv6 routers

This blog post is part of a series on ipv6. In part 1, I provided an overview of ipv6 and looked at Teredo, the technology built into Windows Vista; in part 2, I looked at AYIYA tunnels through aiccu, using sixxs net as a tunnel broker. Part 2.5 is a collection of useful ipv6 tidbits, and part 3 describes gogonet/freenet6 tunnels.

In part 4, I will describe the IPv6 tunnel I have been using all along since 2008: A Hurricane Electric 6in4 tunnel, typically terminating on a router, though it could be terminated on a PC, as well. I aim to break part 4 into chunks, each describing setup for a different make and model of router.

Provisioning of the tunnel

Make sure the router you will be using allows itself to be pinged from either “the Internet”, or at the least from HE’s server, currently66.220.2.74.

Sign up with Hurricane’s Electric tunnelbroker.net service.

Once signed in, under “user functions”, choose “Create Regular Tunnel”.

Enter the IPv4 endpoint, and hit “Submit”. If you are a home user, your IPv4 endpoint is the public IP your ISP assigned to you, see whatismyip.org.

And you are done. Helpfully, the tunnel details page also allows you to get sample configurations for a variety of PC and router operating systems, including Linux, Windows, Cisco IOS, Juniper JunOS and Juniper ScreenOS.

Updating your dynamic IPv4 address

If you are in a home environment, your public IPv4 address may change from time to time. You can update it from the tunnel details page, or you can use tunnelbroker.net’s ipv4 update page that is intended to be used from a script, for automatic updates.

Routers supporting 6in4 tunnels

Whether enterprise class or home router, here are some of the devices that support 6to4 with 6in4 tunnels today (February 2010). On the home router side, it’s clear that it is early days yet. Comcast’s ipv6 trials may change the competitive landscape here.


Any SSG or ISG firewall running ScreenOS 6.0.0 or later, as well as (with some limitations) Netscreen firewalls on ScreenOS 5.4.0. Part 4.1 describes the setup.

Any JunOS router – J-Series, M-Series, E-Series, T-Series, &c. All the way back to JunOS 9.1 if need be.

Any SRX firewall, with the caveat that SRX does not yet support ipv6 firewalling as of JunOS 10.1, though it does support ipv6 tunneling and routing.

EX switches do not support ipv6 tunnels yet, though the feature is road-mapped.


It’s the usual mess of IOS versions depending on model, paired with feature set. A very Cisco-savvy fellow over at the HE forums has an excellent breakdown. In a nutshell, IOS 12.4 or later should work, and you’ll need the right feature set.

Switch support for IPv6 is good. You’ll need to check model / IOS version / feature set here, too.


Apple Airport Extreme supports 6to4, and a one-click tunnel provisioning, too. This is the only home router that I’d be confident to use for IPv6 today, without needing to fear that a firmware update would break IPv6. Mainly because a firmware update did break IPv6, and Apple fixed it in v1.5. For this router, IPv6 is an officially supported feature.

[Update 2010-04-28] Comcast will use this router in their IPv6 dual-stack trials, as one of three choices.


Comcast will use the Netgear WNR3500 and Netgear WNR1000 in their IPv6 dual-stack trials. Whether these routers support 6in4 tunnels is unknown to me at this point.


[Update 2011-08-03: D-Link have updated their site with a list of devices supporting native IPv6] According to D-Link, the following router models support IPv6. Comcast are using the DIR-655 and DIR-825 in their native dualstack IPv6 trial.

D-Link IPv6 Certified Routers

  • DIR-601 Wireless N 150 Home Router (Hardware Revision A1)
  • DIR-615 Wireless N 300 Router (Hardware Revision E1)
  • DIR-632 Wireless N 8-Port Router (Hardware Revision A1)
  • DIR-655 Xtreme N Gigabit Router (Hardware Revision B1)
  • DIR-825 Xtreme N Dual Band Gigabit Router (Hardware Revision B1)
  • DHP-1320 Wireless N PowerLine Router (Hardware Revision A1)

Other IPv6 Certified Products

  • DHP-W306AV PowerLine AV Wireless N Extender (Hardware Revision A1)
  • DAP-1350 Wireless N Pocket Router and Access Point (Hardware Revision A1)
  • DAP-1360 Wireless N Range Extender (Hardware Revision B1)
  • DAP-2590 AirPremier N Dual Band PoE Access Point

D-Link state that their DSL modem routers, the DSL-2540B and DSL-2640B also support IPv6.

D-Link DGS-3200 and DGS-3600 switches officially support IPv6.


WRT610N, with reports that firmware updates break ipv6 support and that Linksys support is firm that ipv6 is not an officially supported feature. More testing is in order here, too.

[Update] A Linksys live chat operator tells me that native IPv6 is supported on the WRT610N, and that there is no official documentation for this. No word on tunnels. I have reached out to their press office to get details and will update if/when I get an answer.

[Update] The Comcast trial forums float the WRVS4400N as supporting tunneled and native IPv6.

Buffalo Technology

A “number of” their wireless products support ipv6. I have reached out to their press office to get details and will update if/when I get an answer.


FRITZ!Box 7270 (experimental “Labor” version)

I have reached out to their press office to get details and will update if/when I get an answer.

NIST releases ipv6 security draft

NIST, the “National Institute of Standards and Technology” in the US, has released a draft paper titled “Guidelines for the Secure Deployment of IPv6“. It is a far-ranging paper that looks at IPv6 features one by one and discusses their security ramifications. It also carries some good discussion about IPv6 address allocation and IPv6 transitional options. Recommended read if you are looking to deploy IPv6 in a corporate / educational / governmental environment. Anything bigger than your home, in essence.

ipv6 at home: Comcast ipv6 trials

I’m admittedly late to the party with this, as it’s a January 27th announcement. Comcast is gearing up for public ipv6 trials starting in April, and they’re looking for guinea pigs trial users.

[Update 2010-02-26] I just received an email from Comcast. They’ll start ramping up 6RD trials nationwide. Dual-stack trials will be regionally limited. Trial users that do not have IPv6-ready equipment will receive equipment that is ready, including what Comcast calls a “gateway” (home router). They may start contacting volunteers in a month, and expect to start some of these trials within 3 months.

There’ll be four total phases to the trial:

Q2 2010

IPv6 tunneled over IPv4 using 6RD. If you’re using one of the tunnel methods I describe in this blog today, you’re familiar with this.

Native dual stack. You’ll have both an ipv4 address and ipv6 addressing natively. Your router will need to support ipv6.

Q3 2010

IPv4 tunneled over IPv6, dubbed “Dual Stack Lite”. You’ll have a private IPv4 address, and use a tunnel over IPv6 to share one public IPv4 address with several other subscribers. Interesting approach.

Business class dual stack

In other “late to the party” news, Google turned up ipv6 on youtube sometime in January. Full production, caused a big spike in v6 traffic, and it seems to be working just fine.

Elitegroup (ECS) customer support: Buyer beware

I will tell you a story of my experience with Elitegroup‘s (ECS) customer support, a story that starts on New Year’s Eve 2009 and continues today. The point of the story, beyond just venting my spleen that is, is to serve as a note of caution to really look into the support record of any company you may be buying parts from: And, with any luck, the comments may give a fuller picture of support in the graphics card industry, beyond my one case.

In a nutshell, my graphics card failed. ECS sent a replacement, which also failed. Today, Feb 23rd, they are telling me I should wait another 2 months for them to contact China, so ECS may determine whether they will replace the replacement, and get me back on my feet with a working card.

In a little more detail, then:

On Dec 31st, my then 2-year old 8800GT graphics card failed. The failure was not subtle: When the card was connected to power, the PSU would shut down immediately to protect itself. Replace the card with a 9800GT (by BFG in that case), and everything’s fine again. This failure wasn’t entirely unexpected: NVidia has had issues with the manufacturing choices they made, leading to a higher than normal rate of failure, and getting worse when things are powered on and off a lot – like in a desktop PC.

It took ECS 30 days to replace my card. They replaced it with a 9800GTX+, since they didn’t have my model any more. Fair enough. The card they sent me as a replacement was used – refurbished, you might call it – and while it could boot Windows, it failed consistently under load. That load being Hulu on 480p with Flash 10.1 for acceleration, and DDO on maximum details. The card didn’t get any hotter than maybe 75C during these tests. It’d take maybe 5-10 minutes for DDO to show a “black screen”. Now, I had seen this failure before, with my 8800GT: Before it packed in completely, it would show this issue. I underclocked it, and it limped along for another month before giving up the ghost completely. So I had a good idea that what I was looking at was another card failure. I underclocked this 9800GTX+, which helped a little, but did not stabilize it. Over the course of a week, the failures on the underclocked card got more frequent.

So I contacted ECS again, to have the replacement replaced. They asked me to test it on a motherboard with an NVidia chipset: “Since this graphics card is an NVIDIA card then please try an nvidia chipset motherboard to test it on”. I happen to have another system with an NForce4 chipset in the house. What if I hadn’t? What does the motherboard chipset have to do with the graphics card failing?

The card was duly tested on the other system, and the fault followed the card. I got an RMA number and sent the card back to ECS. In the meantime, I installed another 9800GT in my system, this time by PNY. With this card, my system is entirely stable.

When the 9800GTX+ that ECS had sent me as a replacement arrived back at ECS, they started testing it in tech support. Tech support cannot reproduce the failures I am seeing. After days and several phone calls, I am now being told that the card needs to be sent to China for testing, and it may be 2 months before ECS have results from that.

To recap:

– Card is faulty in my system

– Fault follows the card to another system

– My system is stable with another card

I’d say that’s conclusive, even when ECS can’t reproduce in their lab. It may be they run it in an open bench environment, and it’s a lot cooler there than in a tower. After all, if this is related to NVidia’s process issues, thermal does play into it. Or it may be their tests just aren’t as hard on the card as DDO is.

One wonders – at what point is the effort to prove the customer wrong just not worth the effort any more? And why would any company go to great lengths to prove the customer wrong, at any rate?

I’ve asked ECS to escalate this to a supervisor. I have no desire to wait 2 months to then be told by Chinese technicians that they can’t reproduce my fault.

[Update 2010-02-24]

ECS tech support did not have a supervisor call me as I requested. They are now offering me a refurbished 9800GTE. I’m nervous – their previous refurb didn’t do so well. And I decided to take them up on the offer and give it a try. Maybe 3rd time’s the charm.

I have only so many cycles to burn on this. That’s what I’m telling myself, anyhow. Tech support as a process of user attrition – this is a truly miserable experience.

[Update 2010-03-09]

The 9800GTE replacement card is stable in my system. It took a bit over two months to get this RMA done, and more than a fair bit of badgering. All’s well that ends well.