Oct 032018
 

So, I’ll admit to looking at AX.25 with the typical modems available (the classical 1200-baud AFSK and the more modern G3RUH modem which runs at a blistering 9600 baud… look out 5G!) years ago and wondering “what’s the point”?

It was Brisbane Area WICEN’s involvement in the International Rally of Queensland that changed my view somewhat.  This was an event that, until CAMS knocked it on the head, ran annually in the Imbil State Forest up in the Sunshine Coast hinterland.

There, WICEN used it for forwarding the scores of drivers as they passed through each stage of the rally.  A checkpoint would be at the start and finish of each stage, and a packet network would be set up with digipeaters in strategic locations and a base station, often located at the Imbil school.

The organisers of IRoQ did experiment with other ways of getting scores through, including hiring bandwidth on satellites, flying planes around in circles over the area, and other shenanigans.  Although these systems had faster throughput speeds, one thing they had which we did not have, was latency.  The score would arrive back at base long before the car had left the check point.

This freed up the analogue FM network for reporting other more serious matters.

In addition to this kind of work, WICEN also help out with horse endurance rides.  Traditionally we’ve just relied on good ol’e analogue FM radio, but in events such as the Tom Quilty, there has been a desire to use packet as a mechanism for reporting when horses arrive at given checkpoints and to perhaps enable autonomous stations that can detect horses via RFID and report those “back to base” to deter riders from cheating.

The challenge of AX.25 is two-fold:

  1. With the exception of Linux, no other OS has any kind of baked-in support for it, so writing applications that can interact with it means either implementing your own AX.25 stack or interfacing to some third-party stack such as BPQ.
  2. Due to the specialised stack, applications often have to run as privileged applications, can have problems with firewalling, etc.

The AX.25 protocol does do static routing.  It offers connected-mode links (like TCP) and a connectionless-mode (like UDP), and there are at least two routing protocols I know of that allow for dynamic routing (ROSE, Net/ROM).  There is a standard for doing IPv4 over AX.25, but you still need to manage the allocation of addresses and other details, it isn’t plug-and-play.

Net/ROM would make an ideal way to forward 6LoWPAN traffic, except it only does connected mode, and doing IP over a “TCP-like” link is really a bad idea.  (Anything that does automatic repeat requests really messes with TCP/IP.)

I have no idea whether ROSE does the connectionless mode, but the idea of needing to come up with a 10-digit numeric “address” is a real turn-off.

If the address used can be derived off the call-sign of the operator, that makes life a lot easier.

The IPv6 address format has enough bits to do that.  To me the most obvious way would be to derive a MAC address from a call-sign and an arbitrarily chosen digit (0-7).  It would be reversible of course, and since the MAC address is used in SLAAC, you would see the station’s call-sign in the IPv6 address.

The thinking is that there’s a lot of problems that have been solved in 6LoWPAN.  Discovery of services for example is handled using mechanisms like mDNS and CoRE RD.  We don’t need to forward Internet traffic, although being able to pull up the Mt. Kanigan and Mt. Stapylton radars over such a network would be real handy at times (yes, I know it’ll be slow).

The OS will view the packet network like a VPN, and so writing applications that can talk over packet will be no different to writing any other kind of network software.  Any consumer desktop OS written in the last 16 years has the necessary infrastructure to support it (even Windows 2000, there was a downloadable add-on for it).

Linking two separate “mesh” networks via point-to-point links is also trivial.  Each mesh will of course see the other as “external” but participants on both can nonetheless communicate.

The guts of 6LoWPAN is in RFC-4944.  This specifies details about how the IPv6 datagram is encoded as a IEEE 802.15.4 payload, and how the infrastructure within 802.15.4 is used to route IPv6.  Gnarly details like how fragmentation of a 1280-byte IPv6 datagram into something that will fit the 128-byte maximum 802.15.4 frames is handled here.  For what it’s worth, AX.25 allows 255 bytes (or was it 256?), so we’re ahead there.

Crucially, it is assumed that the 802.15.4 layer can figure out how to get from node A to node Z via B… C…, etc.  802.15.4 networks are managed by a PAN coordinator, which provides various services to the network.

AX.25 makes this “our problem”.  Yes the sender of a frame can direct which digipeaters a frame should be passed to, but they have to figure that out.  It’s like sending an email by UUCP, you need a map of the Internet to figure out what someone’s address is relative to your site.

Plain AX.25 digipeaters will of course be part of the mix, so having the ability for a node stuck on one side of such a digipeater would be worth having, but ultimately, the aim here will be to provide a route discovery mechanism in place that, knowing a few static digipeater routes, can figure out who is able to hear whom, and route traffic accordingly.

Nov 062016
 

Sometimes, it is desirable to have a TLS-based VPN tunnel for those times when you’re stuck behind an oppressive firewall and need to have secure communications to the outside world.  Maybe you’re visiting China, maybe you’re making an IoT device and don’t want to open your customers’ networks to world+dog by making your device easy to compromise (or have it pick on Brian Krebs).

OpenVPN is able to share a port with a non OpenVPN server.  When a tunnel is established, it looks almost identical to HTTPS traffic because both use TLS.  The only dead giveaway would be the OpenVPN session lasts longer, but then again, in this day of websockets and long polling, who knows how valid that assumption will be?

The lines needed to pull this magic off?  Here, we have sniproxy listening on port 65443. You can use nginx, Apache, or any other HTTPS web server here.  It need only be listening on the IPv4 loopback interface (127.0.0.1) since all connections will be from OpenVPN.

port 443
port-share localhost 65443

There’s one downside.  OpenVPN will not listen on both IPv4 and IPv6.  In fact, it takes a ritual sacrifice to get it to listen to an IPv6 socket at all.  On UDP, it’s somewhat understandable, and yes, they’re working on it.  On TCP, it’s inexcusable, the problems that plague dual-stack sockets on UDP mostly aren’t a problem on TCP.

It’s also impossible to selectively monitor ports.  There’s a workaround however.  Two, in fact.  Both involve deploying a “proxy” to re-direct the traffic.  So to start with, change that “port 443” to another port number, say 65444, and whilst you’re there, you might as well bind OpenVPN to loopback:

local 127.0.0.1
port 65444
port-share localhost 65443

Port 443 is now unbound and you can now set up your proxy.

Workaround 1: redirect using xinetd

The venerable xinetd superserver has a rather handy port redirection feature.  This has the bonus that the endpoint need not be on the same machine, or be dual-stack.


service https_port_forward
{
flags = IPv6               # Use AF_INET6 as the protocol family
disable = no               # Enable this service
type = UNLISTED            # Not listed in standard system file
socket_type = stream       # Use "stream" socket (aka TCP)
protocol = tcp             # Protocol used by the service
user = nobody              # Run proxy as user 'nobody'
wait = no                  # Do not wait for close, spawn a thread instead
redirect = 127.0.0.1 65444 # Where OpenVPN is listening
only_from = ::/0 0.0.0.0/0 # Allow world + dog
port = 443                 # Listen on port 443
}

Workaround 2: socat and supervisord

socat is a Swiss Army knife of networking, able to tunnel just about anything to anything else.  I was actually going to deploy that route, but whilst I was waiting for socat and supervisord to install, I decided to explore xinetd‘s capabilities.  Both will do the job however.

There is a catch though, socat does not daemonise. So you need something that will start it automatically and re-start it if it fails. You might be able to achieve this with systemd, here I’ll use supervisord to do that task.

The command to run is:
socat TCP6-LISTEN:443,fork TCP4:127.0.0.1:65444

and in supervisord you configure this accordingly:

[program:httpsredirect]
directory=/var/run
command=socat TCP6-LISTEN:443,fork TCP4:127.0.0.1:65444"
redirect_stderr=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
autostart=true
autorestart=true

Jun 232011
 

It was interesting when I posted a news article to the WIA regarding IPv6, how quickly it got shot down by “experts”.

A recent addition to our network was a 2008-model Apple MacBook, which I have dual-booting Gentoo and MacOS X 10.6.7 nicely.  One quirk of this particular laptop though, is that it will, when running its native OS, intermittently drop off the IPv4-only network.

The first tip-off to this is usually things like Skype ceasing to work.  Then I’ll notice DNS isn’t resolving (DNS is IPv6-accessible, but not many systems support RDNSS).

As a work-around to the problem, and also for my own self-education, I decided I’d have a crack at getting NAT64 and DNS64 to work.  What are they exactly?

NAT64 as the name suggests, is a variant of NAT that translates IPv6 to IPv4.  In doing so, allowing my MacBook that’s just disappeared from the face of the IPv4-only world, to still access the IPv4-part of the Internet.

DNS64 is a service that synthesizes AAAA records for host names that do not provide one.

The two work together to provide Internet access to an IPv6 only host.

What you will need to know

Make sure you have the following information on-hand.  I’ll use the following examples:

  • Your server’s IPv4 address on the local network: e.g. 192.168.0.1/24
  • IPv4 NAT address pool: This must not overlap with your existing networks.
    Examples use 192.168.255.0/24, I used 172.16.24.0/24
  • TAYGA’s tunnel IPv4 address: This will be the first address in the above subnet (i.e. 172.16.24.1)
  • Your network’s IPv6 subnet: e.g. 2001:dead:beef:1200::/56
  • IPv6 NAT address pool: This needs to be a non-overlapping portion of your address space.  In my case, I’m borrowing a /56 from AARNet, and I used a /64 for this, setting the lower 8-bits of the prefix to 0x64.  It only needs to be /96 in size.
    Example used: 2001:dead:beef:1264::/96

NAT64 setup

To get NAT64 working; start by installing TAYGA.  This is a userspace daemon uses the TUN device to route between IPv4 and IPv6.  On Gentoo, begin by running emerge tayga.  (You may need to keyword it.)

This installs the binary, but crucially, it comes with no init scripts.  You will need to create one yourself like this:

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-libs/gpm/files/gpm.rc6,v 1.12 2004/07/15 01:02:02 agriffis Exp $

depend() {
    need gw6c net.nat64
}

start() {
    ebegin "Starting tayga"
    start-stop-daemon --start --quiet -p /var/run/tayga.pid \
        --exec /usr/sbin/tayga -- \
        -u nobody -g nogroup \
        --pidfile /var/run/tayga.pid
    eend ${?}
}

stop() {
    ebegin "Stopping tayga"
    start-stop-daemon --stop --quiet --pidfile /var/run/tayga.pid
    eend ${?}
}

Now, edit /etc/tayga.conf, using /etc/tayga.conf.example as a guide.  There are comments provided.  The following are the settings I used (with the above addresses):

#
# TAYGA's IPv4 address.  This is NOT your router's IPv4 address!  TAYGA
# requires its own address because it acts as an IPv4 and IPv6 router, and
# needs to be able to send ICMP messages.  TAYGA will also respond to ICMP
# echo requests (ping) at this address.
#
# This address can safely be located inside the dynamic-pool prefix.
#
# Mandatory.
#
ipv4-addr 172.16.24.1
# ... etc ...
#
# The NAT64 prefix.  The IPv4 address space is mapped into the IPv6 address
# space by prepending this prefix to the IPv4 address.  Using a /96 prefix is
# recommended in most situations, but all lengths specified in RFC 6052 are
# supported.
#
# This must be a prefix selected from your organization's IPv6 address space
# or the Well-Known Prefix 64:ff9b::/96.  Note that using the Well-Known
# Prefix will prohibit IPv6 hosts from contacting IPv4 hosts that have private
# (RFC1918) addresses, per RFC 6052.
#
# The NAT64 prefix need not be specified if all required address mappings are
# listed in `map' directives.  (See below.)
#
# Optional.
#
prefix 2001:dead:beef:1264::/96
#
# Dynamic pool prefix.  IPv6 hosts which send traffic through TAYGA (and do
# not correspond to a static map or an IPv4-translatable address in the NAT64
# prefix) will be assigned an IPv4 address from the dynamic pool.  Dynamic
# maps are valid for 124 minutes after the last matching packet is seen.
#
# If no unassigned addresses remain in the dynamic pool (or no dynamic pool is
# configured), packets from unknown IPv6 hosts will be rejected with an ICMP
# unreachable error.
#
# Optional.
#
dynamic-pool 172.16.24.0/24
# ... etc ...

Now, having done this… you just need to make sure the nat64 device gets created and initialised by openrc.  In /etc/conf.d/net:

# NAT64 configuration for TAYGA
config_nat64=(
   "192.168.0.1/24"
   "2001:dead:beef:1264::1/64"
)
routes_nat64=(
        "172.16.24.0/24"
        "2001:dead:beef:1264::/96"
)

preup() {
        case ${IFACE} in
                nat64)
                        /usr/sbin/tayga --mktun
                        ;;
        esac
}

Now, symlink /etc/init.d/net.lo to /etc/init.d/net.nat64, start the tayga service, and you should find that you can ping e.g. 2001:dead:beef:1264::8.8.8.8 (8.8.8.8 is Google DNS).

DNS64 setup

All good and well if you know the IP addresses, but most people don’t.  Now emerge totd.  Use /usr/share/doc/totd-VERSION/totd.conf.sample.bz2 as an example for configuring /etc/totd.conf:

; $Id: totd.conf.sample,v 1.9 2003/09/17 15:56:20 dillema Exp $
; Totd sample configuration file
; you can have multiple forwarders, totd will always prefer
; forwarders listed early and only use forwarders listed later
; if the first ones are unresponsive.
forwarder 2001:dead:beef:1234::1 port 65053
forwarder 127.0.0.1 port 65053
forwarder 8.8.8.8 port 53
forwarder 8.8.4.4 port 53

; you can have multiple prefixes or even no prefixes at all
; totd uses them in round-robin fashion
prefix 2001:dead:beef:1264::
; the port totd listens on for incoming requests
port 53
; the pidfile to use (default: /var/run/totd.pid)
pidfile /var/run/totd.pid
; interfaces totd listens on (UDP only for now and not on Linux)
; If left out totd will only open wildcard sockets.
;interfaces br0
; 6to4 reverse lookup
stf

In my case, I have a local caching name-server (BIND), which I’ve moved to port 65053. The trick-or-treat daemon now sits on port 53 where the rest of the network expects it. You can now start the totd service, point your /etc/resolv.conf files to it, and everything should Just Work.

Testing

Easiest way is to shut off IPv4, and set up /etc/resolv.conf on your client with the IPv6 address of your server running totd.  You should now be able to browse IPv4-only sites as if IPv4 were running.  I achieved this test by plugging into Ethernet, turning off wicd (it kept wanting to start-up dhcpcd), then manually bringing the interface up and configuring /etc/resolv.conf.

Jun 082011
 

Well… has anyone noticed anything different about the ‘net?

stuartl@atomos ~ $ host www.google.com.au
www.google.com.au is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.237.52
www.l.google.com has address 74.125.237.48
www.l.google.com has address 74.125.237.49
www.l.google.com has address 74.125.237.50
www.l.google.com has address 74.125.237.51
www.l.google.com has IPv6 address 2404:6800:4006:802::1011

I knew World IPv6 day was coming up, but it seems it snuck up on me and I barely noticed. Likely a testament to the fact we run a dual-stack network here, and so everything magically Just Worked™ as it should. Indeed, a lot of websites are now dual-stack, as is much of the gentoo.org infrastructure, Google (as seen above), FaceBook, and numerous other sites.

Sadly, a lot of ISPs here in Australia did the demented ostrich act when it came to IPv6. I wonder how many technical support calls they received, with users complaining about websites being slow to load up or failing to connect.

iTel, formerly “Global Info-Links”, now calling themselves “South East Community Telco“… were one of the masses that drove their RFC791-only heads in the sand and pretended that the entire Internet can be compressed into 32-bits of address space. We’ve been waiting to hear back from them on their plans for addressing since January as we’d like to upgrade the 512/128kbps ADSL link we use here. (Anyone noticed this site tends to load up a bit slow? That 128kbps figure is the reason why.)

We’ve been with this ISP since 1996. That’s quite a long innings… We’ve stayed put because until now we’ve been happy with the service. 512kbps was quite fast when we upgraded from 56kbps PSTN dialup (14.4kbps dialup when we first started… still have that modem too!). These days it plods along, but the 128kbps uplink is a notable thorn in my side with my telecommuting. So we’re looking at ADSL2+.

However, there’s one hitch. iTel is only a fairly small ISP. At the moment they do the noble thing of providing static public addresses on IPv4 for all fixed-broadband customers, but how long will that last? The last thing I want, is to sign up a contract for 12 months, then find out that in 6 months they need to move us behind CGN (Carrier grade NAT) to squeeze in some more customers. That won’t fly for us. I’d ideally like to ditch the 6-in-4 tunnel I have with AARNet and go native, or at the very least, swap it with one terminated at the ISP, but that doesn’t seem to be happening anytime soon.

At the moment there is only one ISP I know of that offers any sort of IPv6 connectivity. Internode. Kudos to them for taking the pioneering step! I’m seriously looking in their direction. I’m also hoping the NBN that we keep hearing about, is IPv6 enabled… and I’m holding out with the hope that our little suburb might soon be getting the long strands of glass laid down our street. If it’s only another year or so, it may be worth just hanging on with ADSL1 until then.

Thankfully, we do have the 6-in-4 tunnel through AARNet (and my greatest gratitude to them for providing it). There is a growing community on this newer protocol… I’m also happy to report absolutely 0 spam via IPv6… any spam or malware thus far has been via IPv4 … although I know this won’t last. The good news there is that with one unique address per computer (instead of per customer, or worse, per 100+ customers), it should be easier to track down the guilty party causing such Internet shenanigans. CGN by comparison is likely to be a spammer’s playground.

What am I doing about IPv6 deployment? Aside from my small-time tinkering with the network here… any socket programming I do today is at the very least dual-stack. One of my hobby projects is a digital mode stack for amateur radio… if I get my way it’ll be IPv6-only when used on a computer network.

One of my work projects involves interfacing some proprietary software to some power meters using RS-232 and RS-485 to Ethernet bridging devices. Even though the devices themselves are IPv4 only (and will be for the foreseeable future), I’m designing the software to handle IPv6. Doing this, future proofs the software. Surprisingly, I’m finding it easier to just design for dual-stack than it is to develop a IPv4-only application. If you’re building an application today, dual-stack IMHO must be part of the strategy if the application is going to work beyond this decade.

Some have asked about IPv6 on packet… sadly AX.25 packet does not go anywhere near fast enough to make IPv6 (or indeed, IPv4) networking a viable option on packet radio using existing TNCs… however I think IPv6 will, and should, play a much bigger part in amateur radio communications than it presently does… we can’t expect to hold on to the 44.0.0.0/8 subnet for much longer.

To the ISPs that are lagging behind, I say get moving! IPv4 is older than I am! This is especially true of the smaller ISPs… if you don’t move, you will get squeezed out of the future Internet connection market as address space gets consumed. To the nay-sayers who keep telling us that something else will replace IPv4, to you I say get moving… you haven’t got long to invent this magical silver bullet, in fact I say you’ve left it too late.

Sep 122005
 

After some tinkering today, I managed to figure out the wonderous black art that is IPv6. Now I get to discover the Internet that IPv4 user’s don’t see.

How does one get hooked up to IPv6? Well, if your ISP doesn’t support it, then you have to establish an IPv6-in-IPv4 tunnel with an IPv6 broker. Since I’m in Australia, naturally, I set up an account with AARNet, and requested a tunnel through them.

Gentoo have a nice little guide, that steps users through setting up with either 6Bone or Freenet6… however it seems AARNet do things slightly differently.

The way I set things up was as follows…

Connecting a host to IPv6 via AARNet

Before we start, you’ll want to make sure you’ve got IPv6 support in your kernel. If you see a directory called /proc/sys/net/ipv6, then chances are good, you’ve got what it takes. 🙂

First, create an account. This is the username and password you’ll use to request the tunnel later. You’ll be emailed a system generated password. You only get one, and there’s no password changing facility (that I can see), so it would be adventageous to keep this email safe.

Next, fill out this form. If you’re just wanting to hook up a single host, then ignore the “Request for /48 prefix”. Otherwise, you’ll need to check that box — in the “Interface Name” field, enter the interface name for your internal LAN interface (e.g. eth1 in my case). You’ll then be asked for your username and password before downloading a setup shell script (linux.sh if you selected Linux).

Now, Place this linux.sh somewhere convenient. I stuffed it into /etc/setup-ipv6. This script is what you’ll use to establish the tunnel. I call it from my /etc/conf.d/local.start (rc.local for those playing along with other distributions), so my tunnel is established at boot.

Right, with that over, it’s now time to install the tools necessary. On Gentoo, simply USE=ipv6 emerge iputils iproute2 freenet6 — Freenet6 use the exact same tools. Other distributions, AARNet provide the tools from their front page. You’ll also want iproute2, and a version of iputils with IPv6 support.
Gentoo users may find it adventageous to set USE=ipv6 in their /etc/make.conf, and update their system so that they can make use of IPv6 support in any applications able to utilise it.

Lastly, we need to configure tspc, the tunnel client. On Gentoo, edit /etc/freenet6/tspc.conf (just hack up the example config). Place in there, the username and password you were given from AARNet, and down the bottom, change the server= line to read broker.aarnet.net.au. You’ll also want to edit the linux.sh file, to make sure the directories mentioned are correct, in particular, TSP_HOME_DIR should point to the directory containing tspc.conf.

And now we’re ready to bring up the tunnel. Run sh linux.sh (or whatever you ended up calling it). You should see something like this…

(23:32) www ~ # /etc/setup-ipv6
--- Start of configuration script. ---
Script:  setup-ipv6
sit1 setup
Setting up link to 202.158.196.131
This host is: 2001:0388:f000:0000:0000:0000:0000:0279/
Adding default route
Router configuration
Kernel setup
net.ipv6.conf.all.forwarding = 1
Adding prefix to eth1
Starting radvd: /usr/sbin/radvd -u radvd -C /etc/freenet6/tsprtadvd.conf
--- End of configuration script. ---
(23:32) www ~ # _

You’re now running IPv6. Go on, get out there… explore. 🙂 To check you’re really browsing IPv6, try pointing an IRC client at irc.ipv6.freenode.net (Ohh, and don’t forget to pop in to one of the Gentoo channels and say Hi ;-)), or point your web browser at the KAME website. If you’re running IPv6, their tortise should be dancing (it’s an animated GIF). You can also try pinging various sites such as irc.ipv6.freenode.net or www.kame.net using the ping6 utility.

Sharing the love

So, suppose you asked for a /48 prefix, and you’ve got a bunch of machines sitting behind the router that you want on IPv6 too. Easy fixed. You’ve got a couple of options. One is to set up dhcpv6, or the other, is to simply use radvd. The latter works out of the box, the tunnel script automatically configures radvd for you.

On Gentoo, simply emerge radvd. Then restart your tunnel script. It should start radvd, and within a few seconds, the other machines on your network should receive the route/adressing advertisments, and automatically configure themselves for IPv6.

This is only half of the story though … You then have to enable IP forwarding on your server. (Sound familiar? Should do… same as IPv4).
Simply run echo 1 > /proc/sys/net/ipv6/conf/default/forwarding, and you should see the packets start flowing.

Keeping the nasties out

Now that you’ve got routing set up, it’s time to lay down the law regarding firewall rules. Quite obviously, you don’t want the outside riffraff upsetting your delicate hardware unless it’s got a specific invitation to do so. Make sure you’ve got netfilter6 support in your kernel, and the ip6tables utility. (distributed with iptables)

At the moment, there’s no connection tracking in IPv6, nor is there any network address translation (which is unnecessary on IPv6 anyways). The following is what I use for my firewalling rules, adapt to taste.

# Generated by ip6tables-save v1.3.2 on Sun Sep 11 23:57:08 2005
*mangle
:PREROUTING ACCEPT [16827:6712869]
:INPUT ACCEPT [1297:98415]
:FORWARD ACCEPT [15530:6614454]
:OUTPUT ACCEPT [1629:131392]
:POSTROUTING ACCEPT [17230:6752830]
COMMIT
# Completed on Sun Sep 11 23:57:08 2005
# Generated by ip6tables-save v1.3.2 on Sun Sep 11 23:57:08 2005
*filter
# By default, drop anything comming in or through us.
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Allow all ICMP traffic
-A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT

# Local LAN interfaces (note, since I'm behind an ADSL router, all my interfaces are private, except sit1)
-A INPUT -s ::/0 -d ::/0 -i eth+ -j ACCEPT

# Allow SSH and IRC connections (I'd open more, but I'll need DNS working first)
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 6667 -j ACCEPT

# Forwarding rules...
# Allow internal traffic OUT
-A FORWARD -s ::/0 -d ::/0 -i eth+ -j ACCEPT

# Allow established connections back IN
-A FORWARD -s ::/0 -d ::/0 -i sit1 -o eth+ -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT

# Allow ICMP traffic
-A FORWARD -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT

# Log anything else
-A FORWARD -s ::/0 -d ::/0 -j LOG --log-prefix "FORWARD IPv6: "
COMMIT
# Completed on Sun Sep 11 23:57:08 2005

It’s a crude firewall, but it works. 🙂
The above guide, is far from being perfect, but hopefully my notes above will assist others in migrating to IPv6.