Bart Jansens

SheevaPlug Development Kit

Bart — Wed, 18 Nov 2009 14:42:28 +0000

A few months ago, I decided to purchase a SheevaPlug Development Kit to replace my previous home server which was an old Dell workstation. The main reason to replace the old machine was power usage, for a machine that is sitting idle most of the time, it costs a lot of money to run.
All I needed was a device on which I could run linux to run some typical core network services (DNS, DHCP, NTP) as well a some extras like my internal mail server and proxy. With a power consumption of only a few Watts, the SheevaPlug was ideal for this purpose. Its a pretty small device with the following specifications:

Specifications

1.2GHz Marvell Kirkwood 6281 CPU
512MB DDR2 400MHz RAM
512MB NAND Flash
Gigabit Ethernet
USB 2.0 Host
SDIO interface for SDHC cards
Serial port

Installation

The SheevaPlug is shipped with Ubuntu 9.04 “jaunty” installed. The standard software image does have some issues, so the first thing I did was upgrad to the latest version using the SheevaPlug installer 1.0. This involved attaching the serial console to a PC and running a script which loaded the new software from an USB stick. This wasn't very difficult, but not exactly something a novice should attempt either. The only issue I ran into was that the USB stick used to perform the upgrade couldn't have any partitions on it. So the stick had to be wiped and formatted as one big FAT32 partition (mkfs.vfat -I /dev/sdX).

After the upgrade was completed, the device was ready to be configured just like any other debian-like linux machine.
Because the size of the internal flash is limited, I installed a 4GB SDHC card to mount the directories that are most likely to fill up the storage.

The next issue I ran into was that after logging in via SSH, the device complained about missing nl_BE locales. Because those are not available on the plug and I didn't really need them, I set the locale to en_US by creating /etc/default/locale with the following contents:
LANG="en_US.UTF-8" LANGUAGE="en_US.UTF-8:en"

Software

I installed the following software packages, which are working without issues:

ntp: Internal primary NTP server for use by all clients. Obtains the current time from several external clock sources
bind9: Internal primary DNS server. Hosts the internal DNS zone and accepts DDNS updates from the DHCP server.
dhcp3-server
: Internal DHCP server. Assigns IP addresses to clients and updates the DNS records.
squid3: Proxy server. I don't really need caching, but to access some websites, I need to use an external proxy server. Instead of having to change the client settings every time, this proxy server simply redirects requests for some websites to different upstream proxy servers
postfix: Mail relay. All outbound email needs to pass via this server, again to make it easier to switch to different upstream ISPs and to detect abuse in case a clients gets infected by a virus.
dovecot: Internal IMAP server. This hosts the users mailboxes. Email is retrieved from the ISPs using fetchmail and then stored on this server so that it can be accessed from any computer in the house.

Iphone tethering mobileconfig for Mobistar

Bart — Fri, 03 Jul 2009 07:35:10 +0000

Update: This no longer works with the 3.1 firmware - go thank Apple & Mobistar for that..

The easiest way to enable tethering on your iPhone is to browse to websites like http://help.benm.at which have configuration files that you can install on your phone. However, all the mobileconfig files I found online didn't work for me as they used the wrong APNs. My account needs to use "web.pro.be" for data and "mms.be" for MMS.

So I created my own mobileconfig, attached to this article. Use at your own risk, I'm not going to guarantee that anything here is correct, but it has been confirmed to work (both tethering and MMS) by several people. To install, simply open the attached file from your iPhone.

Of course, keep an eye on your bandwidth consumption, it isn't cheap.

Attachment	Size
mobistar-pro-tethering.mobileconfig	2.04 KB

Policy based routing on Juniper Netscreen firewalls

Bart — Sat, 30 May 2009 13:12:30 +0000

Cleaning up my home directory, I found this presentation I made back in 2006 while beta-testing the policy based routing functionality in netscreen firewalls.

Posting it here as it might be of use to some people.

Netscreen Policy Based Routing

Backing up delicious bookmarks

Bart — Sun, 22 Feb 2009 10:33:36 +0000

Social bookmarking services like Delicious are great for sharing your bookmarks with others or just across multiple computers. But one disadvantage of having them stored in a central location is that you have no control over the backup strategy they use. What if they suffer from a system crash and lose all your data?
If you think I'm just being paranoid, think of what happened to Ma.gnolia recently.

Just to be safe, I wrote a simple little script that takes a copy of all my bookmarks - in XML format - and stores it locally on my PC. Because it is in XML format, converting this data to some other format in the future should be fairly trivial.

#!/bin/sh
 
# Your delicious username and password, separated by a colon
CREDENTIALS="UserName:YourPassword"
# Location where the backup will be stored
BACKUP_DIR="$HOME/backups/del.icio.us"
 
 
if [ ! -d "$BACKUP_DIR" ] ; then
  mkdir -p "$BACKUP_DIR"
fi
 
DATE=$(date +"%Y%m%d")
curl --user "$CREDENTIALS" -o "$BACKUP_DIR/bookmarks-$DATE.xml" -O "https://api.del.icio.us/v1/posts/all"

The script is run from cron on a regular basis, so even if something were to happen to Delicious, I still have a copy of all my bookmarks. Lets hope I never need it.

10 Things I hate about the iPhone

Bart — Wed, 21 Jan 2009 13:22:59 +0000

I have had an iPhone 3G for a while now and it is a pretty nice and fun gadget. Its not as serious as a crackberry, but it does most things I want and there are many interesting apps available for it. Believe it or not, you can even use it as a phone.

There are however, many things about the iPhone that annoy me a lot. Most of them are related to the stupid artificial limitations enforced by Apple, or limitations of their software.

It vibrates when new mail is received, which is pretty normal. But it also does this while you are on a call, not a pleasant feeling.
It has no scheduling for email. Apple likes to say the iPhone is ready for enterprise use, but it misses a lot of the most basic features. As someone who is on-call a lot, my phone needs to be on at night, but I don't want to be woken every time I get an email. They could even save a lot of battery power and roaming costs this way.
The iPhone supports 3G but unlike other phones, no tethering. I want to be able to connect it to my laptop when i'm on the road. It is technically possible, apple just doesn't allow it.
Applications aren't allowed to run in the background. The phone has such huge potential - but this silly rule limits the usefulness of many applications a lot.
The keyboard is difficult to use. In some places you can turn the phone to get a larger keyboard, in others you can't. The dictionary is worthless. In true American style, they completely forgot about countries where people speak multiple languages.
No search functionality. Ever tried looking for an email if you get a hundreds a day? Surprising, for the people who created spotlight.
The touchscreen sometimes registers clicks twice. I kept losing emails until I eventually figured out this was because the last character of my PIN was in the exact same place as the delete button. When I unlocked the phone, it would simply delete the message I had open at the time.
You can't use it as an USB storage device. So you have a phone with multiple GB of storage, that connects to your computer via an USB cable. Then why can't it be used to store files on?
No indication of missed calls. On most phones there is a little led that lights up when you have a missed call, or the screen backlight lights up a little.
Battery life of course. With all functionality enabled, iPhones are usually found in their natural habitat, connected to the USB port of a computer.

Of course I could jailbreak the device to get around many of these limitations, but as I don't really own the device, that is not an option.

All in all, I still like the iPhone, but it is far from perfect. What I dislike most, is the company behind it. Apple fanboys like bashing Windows users, while – as an owner of several Apple products – I believe that Apple is a lot worse than Microsoft. They simply hide it behind a pretty design.

Spam comments left by humans

Bart — Sat, 25 Oct 2008 10:00:39 +0000

In the past few months, Mollom has done a very good job blocking spam on my site. Its accuracy has increased a lot since I first installed it, nearly no spam gets through even though there are hundreds attempts a day.

However, I've been seeing a different kind of spam that does get through. Comments that are left by humans, who can solve the captcha shown by Mollom. These comments are usually on-topic and at first glance appear to be legit, except that the homepage URL of the author links to a spam site. I enabled nofollow a long time ago, but that doesn't appear to make much of a difference anymore.

I've even seen comments that had no link in them at all. I'm not sure what the purpose of those messages is. Maybe they are just checking whether someone removes these comments, or maybe they are trying to confuse Bayesian filters. Either way they are pretty annoying.

I could enable comment moderation on this site, but that would make me the bottleneck as I don't check the queue that often. I noticed that nearly all of these comments show up on a limited number of pages. So I wrote a simple little module that allows me to enable comment moderation for individual nodes and enabled this on the pages that are targeted by these spammers.
This has been running for about a week now and has blocked all such messages. There have even been less attempts, possibly because of the warning message that appears in the comment form. Lets hope it stays this way so I can remove the nofollow tags on links.

Modifying the vmware BIOS

Bart — Sun, 29 Jun 2008 18:48:52 +0000

For a little project that I was working on, I needed to modify the vmware BIOS slightly. After reading VMware BIOS modification - for Linux users, this turned out to be easier than I thought.

Step 1: Get the BIOS

$ objcopy /usr/lib/vmware/bin/vmware-vmx -O binary -j .bios440 --set-section-flags .bios440=a bios440.rom.Z
$ perl -e 'use Compress::Zlib; my $v; read STDIN, $v, 211638; $v = uncompress($v); print $v;' < bios440.rom.Z > bios440.rom

The value "211638" in this last line is the size of bios440.rom.Z.

Step 2: Modify the BIOS

This is a bit more difficult. I have been told the Phoenix BIOS Editor is pretty expensive. Luckily I knew someone who could make the changes for me.

Step 3: Use the new BIOS

After you changed the BIOS to suit your needs, all that is left to do, is edit your virtual machines .vmx file and append one line:

bios440.filename = "path to your BIOS file"

Using the varnish HTTP accelerator - Experiences so far

Bart — Sun, 29 Jun 2008 18:42:53 +0000

A couple weeks ago, I started experimenting with varnish as a reverse proxy server. My setup has changed a lot since then, I like to think it improved. So here are my experiences so far.

Use -trunk (or version 2.0), not the 1.1.2 release

Initially I was using the 1.1.2 release, but I ran into a couple problems. The worst one was the white screen of death for users behind a proxy server, such as squid. There was a problem with the way HTTP/1.0 requests were handled, resulting in blank pages being sent to the client.
The solution was to upgrade to -trunk, it contains several bug fixes and interesting new features and is pretty stable (at least at the moment). I usually don't like using the development version, but at the moment it seems to be the most reliable, and was also recommended by several people.
Version 2.0 will be released soon, use that one when its available.

One thing to keep in mind though is that there is a problem with subroutines. This bug has been reported, so for now I'd recommend not to use them.

Don't duplicate the default VCL functions

In VCL you can have multiple functions with the same name, they will simply be concatenated. This means that you don't have to duplicate the entire default functions if you just want to add a single line. This can simplify your VCL code a lot, and you still benefit from improvements made in the default functions.
For an example, see my new VCL below. I'm using this in all functions except for vcl_recv.

Again, for future reference, a copy of my new VCL code can be found below. As you can see, it has some new "features" but is simpler than the previous one. Note that the backend syntax has changed a little in trunk.

# This is the vcl.conf file for andromeda.motd.be 
 
backend default {
     .host = "208.68.209.225";
     .port = "80";
}
 
#
# handling of request that are received from clients.
# decide whether or not to lookup data in the cache first.
# if we have multiple backends, we could specify them here but for now there is just the default
#
sub vcl_recv {
     # If the client sent an X-Forwarded-For header, remove it. It cannot be trusted.
     unset req.http.X-Forwarded-For;
     # Note that we don't need to add the client ip to the X-Forwarded-For header, varnish will do that for us
 
     if (req.http.Accept-Encoding) {
          # Handle compression correctly. Varnish treats headers literally, not
          # semantically. So it is very well possible that there are cache misses
          # because the headers sent by different browsers aren't the same.
          # @see: http:// varnish.projects.linpro.no/wiki/FAQ/Compression
          if (req.http.Accept-Encoding ~ "gzip") {
               # if the browser supports it, we'll use gzip
               set req.http.Accept-Encoding = "gzip";
          } elsif (req.http.Accept-Encoding ~ "deflate") {
               # next, try deflate if it is supported
               set req.http.Accept-Encoding = "deflate";
          } else {
               # unknown algorithm. Probably junk, remove it
               unset req.http.Accept-Encoding;
          }
     }
 
     # If we get a request for a page that has just been requested by another thread and
     # is still being fetched from the backend, allow serving a cached page so long as it hasn't
     # expired more than 30 seconds ago (prevents thread pileup on cache refreshes).
     # Note that this only works if obj.grace is also set:
     #     "If no in-ttl object was found AND we have a graced object AND it is also
     #      graced by req.grace AND it is being fetched: serve the graced object."
     set req.grace = 30s;
 
     # the default vcl_recv will only look up objects in the cache if there is no cookie
     # present in the request. Therefor, we remove the cookie header from all requests for
     # files which we know to be static.
     #
     # These are drupal-specific:
     # - everything in most of the standard drupal directories.
     # - txt and ico files (most important: robots.txt and favicon.ico)
     if (req.url ~ "^/(files|misc|sites|themes|modules)/" || req.url ~ "\.(txt|ico)$") {
         unset req.http.Cookie; 
     }
 
     # No final action. Continues in the default vcl_recv which will only look up
     # items from the cache for GET and HEAD requests without cookies.
}
 
#
# Called when entering pipe mode
#
sub vcl_pipe {
     # If we don't set the Connection: close header, any following
     # requests from the client will also be piped through and
     # left untouched by varnish. We don't want that.
     set req.http.connection = "close";
 
     # Note: no "pipe" action here - we'll fall back to the default
     # pipe method so that when any changes are made there, we
     # still inherit them.
}
 
#
# Called when the requested object has been retrieved from the
# backend, or the request to the backend has failed
#
sub vcl_fetch {
     if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)") {
          # varnish by default ignores Pragma and Cache-Control headers. It
          # only looks at the "max-age=" value in the Cache-Control header to
          # determine the TTL. So we need this rule so that the cache respects
          # the wishes of the backend application.
          pass;
     }
 
     if (obj.ttl < 180s) {
          # force minimum ttl of 3 minutes for all cached objects.
          set obj.ttl = 180s;
     }
 
     # set the grace period for this object to a maximum of 30s. This is how
     # long after its expire time, it is still allowed to be served from cache if
     # directed to do so by vcl_recv. 
     set obj.grace = 30s;
 
     if (req.http.Authorization && !obj.http.Cache-Control ~ "public") {
          # don't allow caching pages that are protected by basic authentication
          # unless when they explicitly set the cache-control to public.
          pass;
     }
 
     # Note: no final action - continue in the default vcl_fetch
}

Experimenting with Varnish

Bart — Sat, 19 Apr 2008 13:29:19 +0000

As a little experiment, my blog is now running behind a Varnish http accelerator. While squid can be used for this purpose as well, its primary function is a forward proxy. Varnish on the other hand is designed to be a very fast caching reverse proxy server.

I initially tried using the debian etch package of Varnish, but it is a bit outdated. So I ended up building my own package from source. It took a bit of research to configure everything correctly but all in all the configuration was pretty simple and it is easy to read. After a few weeks, I still know what it all means.

There are a few gotchas:

There isn't much documentation.
It will refuse to start if /tmp is mounted "noexec".
Turn off KeepAlives on the backend Apache servers, otherwise you might experience delays when requesting pages.
The VCL "pass" action does not support POST requests. You might come across older configuration examples on the internet that use the "pass" action but that simply doesn't work. You need to use the "pipe" action.
Varnish will only respect the max-age parameter of Cache-Control header by default. Any other values such as those indicating whether or not an object may be cached, will be ignored by default. You need to include some code in your VCL configuration file to handle these headers correctly (see example below).
If you need a large cache (multiple GBs), you need a 64bit system.
There is no persistent cache. Every time you restart varnish, the cache gets wiped. So don't restart unless you really need to.
During load testing, new requests would sometimes hang and ip_conntrack: table full: packet dropped was logged. This wasn't a problem with Varnish but the firewall which couldn't handle that many connections. Increasing the value in net/ipv4/netfilter/ip_conntrack_max fixed that.

All in all, Varnish seems to work pretty well. It can still be improved in many areas but thats to be expected for a v1 release.
Time for me to start testing this on a larger websites.

For future reference, below is the configuration file I've been using.

# configuration file for andromeda
 
backend default {
     set backend.host = "208.68.209.225";
     set backend.port = "80";       
}
 
#
# Block unwanted clients
#
acl blacklisted {
     "192.168.100.100";
}
 
#
# handling of request that are received from clients.
# decide whether or not to lookup data in the cache first.
#
sub vcl_recv {
     # reject malicious requests
     call vcl_recv_sentry;
 
     if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") {
         # Non-RFC2616 or CONNECT which is weird.
         pipe;
     }
     if (req.http.Expect) {
         # Expect is just too hard at present. 
         pipe;
     }
     if (req.request != "GET" && req.request != "HEAD") {
          # we only deal with GET and HEAD
          # note that we need to use "pipe" instead of "pass" here. Pass isn't supported for
          # POST requests
          pipe;
     }
     if (req.http.Authorization) {
         # don't cache pages that are protected by basic authentication
         pass;
     }
     if (req.http.Accept-Encoding) {
         # Handle compression correctly. Varnish treats headers literally, not
         # semantically. So it is very well possible that there are cache misses
         # because the headers sent by different browsers aren't the same.
         # For more info: http:// varnish.projects.linpro.no/wiki/FAQ/Compression
         if (req.http.Accept-Encoding ~ "gzip") {
              # if the browser supports it, we'll use gzip
              set req.http.Accept-Encoding = "gzip";
         } elsif (req.http.Accept-Encoding ~ "deflate") {
              # next, try deflate if it is supported
              set req.http.Accept-Encoding = "deflate";
         } else {
              # unknown algorithm. Probably junk, remove it
              remove req.http.Accept-Encoding;
         }
     }
     if (req.url ~ "\.(jpg|jpeg|gif|png|css|js)$") {
         # allow caching of all images and css/javascript files
         lookup;
     }
     if (req.url ~ "^/files") {
         # anything in drupals files directory is static and may be cached 
         lookup;
     }
     if (req.http.Cookie) {
         # Not cacheable by default
         # TODO: do we even need this? Can't we simply make sure dynamic
         # content never exists in the cache?
         pass;
     }
 
     # every thing else we try to look up in the cache first
     lookup;
}
 
#
# Called when entering pipe mode
#
#sub vcl_pipe {
#     pipe;
#}
 
#
# Called when entering pass mode
#
#sub vcl_pass {
#     pass;
#}
 
#
# Called when entering an object into the cache
#
#sub vcl_hash {
#     set req.hash += req.url;
#     if (req.http.host) {
#          set req.hash += req.http.host;
#     } else {
#          set req.hash += req.http.host;
#     }
#     hash;
#}
 
#
# Called when the requested object was found in the cache
#
sub vcl_hit {
     if (!obj.cacheable) {
         # A response is considered cacheable if all of the following are true:
         # - it is valid
         # - HTTP status code is 200, 203, 300, 301, 302, 404 or 410
         # - it has a non-zero time-to-live when Expires and Cache-Control headers are taken into account.
         pass;
     }
     deliver;
}
 
#
# Called when the requested object was not found in the cache
#
#sub vcl_miss {
#     fetch;
#}
 
#
# Called when the requested object has been retrieved from the
# backend, or the request to the backend has failed
#
sub vcl_fetch {
     if (!obj.valid) {
         # don't cache invalid responses.
         error;
     }
     if (!obj.cacheable) {
         # A response is considered cacheable if all of the following are true:
         # - it is valid
         # - HTTP status code is 200, 203, 300, 301, 302, 404 or 410
         # - it has a non-zero time-to-live when Expires and Cache-Control headers are taken into account.
         #
         # If a response is not cachable, simply pass it along to the client.
         pass;
     }
     if (obj.http.Set-Cookie) {
         # don't cache content that sets cookies (eg dynamic PHP pages).
         pass;
     }
     if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no-cache" || obj.http.Cache-Control ~ "private") {
         # varnish by default ignores Pragma and Cache-Control headers. It
         # only looks at the "max-age=" value in the Cache-Control header to
         # determine the TTL. So we need this rule so that the cache respects
         # the wishes of the backend application.
         pass;
     }
     if (obj.ttl < 180s) {
         # force minimum ttl of 180 seconds for all cached objects.
         set obj.ttl = 180s;
     }
     insert;
}
 
#
# Called before a cached object is delivered to the client
#
#sub vcl_deliver {
#     deliver;
#}
 
#
# Called when an object nears its expiry time
#
#sub vcl_timeout {
#     discard;
#}
 
#
# Called when an object is about to be discarded
#
#sub vcl_discard {
#     discard;
#}
 
#
# Custom routine to detect malicious requests and reject them (called by vcl_recv).
#
sub vcl_recv_sentry {
     if (client.ip ~ blacklisted) {
          error 503 "Your IP has been blocked.";
     }
}

Configuring an IPv6 tunnel on a netscreen SSG firewall

Bart — Sun, 06 Apr 2008 08:57:58 +0000

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.