With IPv6 deployment I'd like to put my money where my mouth is so after the IETF IPv6 only network experiment I wanted to make sure that my jabber server runs both IPv6 and IPv4.  I ran into a bunch of problems:

OpenFire is documented to run IPv6. It draws its capabilities from the java implementation it runs on.

The default Java virtual machine that comes with the FreeBSD ports is diablo-jdk15. That port does not come with IPv6 enabled. You can test that by using the ListNets program that is available from the Java Tutorial site. Copy and paste the code on that page into a file called ListNets.java and test

$ javac ListNets.java
$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01)
Java HotSpot(TM) Client VM (build diablo-1.5.0_07-b01, mixed mode)
$ java ListNets
Display name: lo0
Name: lo0
InetAddress: /127.0.0.1
Display name: rl0
Name: rl0
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1
$

I double checked if there is a compile time configuration option to turn on IPv6 for diablo, there is none. Off to install the jdk1.5 port. Here you have to start with a "make config" in order to enable IPv6 support and compilation will take an hour or so. Once installed the test program will show all interfaces:

$ /usr/local/jdk1.5.0/bin/java -version
java version "1.5.0_14-p8"
Java(TM) 2 Runtime Environment, Standard Edition (build )
Java HotSpot(TM) Client VM (build 1.5.0_14-p8-olaf_28_apr_2008_16_18, mixed mode)
$ /usr/local/jdk1.5.0/bin/java ListNets
Display name: lo0
Name: lo0
InetAddress: /fe80:5:0:0:0:0:0:1
InetAddress: /0:0:0:0:0:0:0:1
InetAddress: /127.0.0.1

Display name: rl0
Name: rl0
InetAddress: /2001:7b8:206:1:0:0:4:53
InetAddress: /2001:7b8:206:1:0:0:0:53
InetAddress: /2001:7b8:206:1:0:0:0:1
InetAddress: /fe80:2:0:0:240:f4ff:fe37:8232
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1

Starting openfire manually, after setting JAVA_HOME to /usr/local/jdk1.5.0/ one can validate that the program actually binds to the tcp6 sockets:

openfire java 96677 11 stream (not connected) openfire java 96677 13 tcp6 *:7777 *:*
openfire java 96677 16 tcp6 *:5269 *:*
openfire java 96677 17 tcp6 *:5229 *:*
openfire java 96677 22 tcp6 *:9090 *:*
openfire java 96677 25 tcp6 *:9091 *:*
openfire java 96677 30 tcp6 *:5222 *:*
openfire java 96677 33 tcp6 *:5223 *:*

Testing the IPv6 connection towards the openfire management interface using "telnet ::1 9090" demonstrates that the IPv6 connection works. However a "telnet 127.0.0.1 9090" fails. So we only have IPv6 and no IPv4 connectivity.

So, why is this?

FreeBSD (and open and net BSD) turn off IPv4 binding to IPv6 sockets by default. This behavior is controlled using the  "net.inet6.ip6.v6only" kernel option. One workaround to solve this problem is to set net.inet6.ip6.v6only=0. However this could lead to cause possible security problems. The security problems in Itojun's draft are the only security issues I am aware off and they can be mitigated by filtering on ::ffff:0:0/96 network traffic e.g. at ones network perimeter. That traffic should not be on the network in the first place (see e.g. informationa RFC number RFC5156 section 2.2).

With  net.inet6.ip6.v6only=1 it is impossible to use AF_INET6 to bind to both IPv6 and IPv4 addresses.

As an alternative I have tried to bind to interfaces explicitly in the openfire.xml configuration but that fails too as it seems that openfire only accepts one instance of the network.interface configuration option. I would argue that on multihomed machines one may want to bind to a subset of the available addresses instead of binding to the wildcard and that allowing for address family agnostic specification of one or more interfaces is the best solution.

Starting two instances of openfire, one on IPv6 and one on IPv4, by specifically binding to the v6 and v4 interfaces is no solution either because the IPv4 server would not know of the presence of clients registered on the IPv6 server.

In order to get a working dual stack openfire running on FreeBSD do the following. 

The HOWTO 

•  add the following lines to your /etc/rc.conf:

  # Allow IPv4-mapped addresses ipv6_ipv4mapping="YES"

• Make sure your java distribution supports IPv6.
  • /usr/ports/java/diablo-jdk15 does not support IPv6
  • /usr/ports/java/jdk15 and /usr/ports/java/jdk16 do support IPv6, but you have to rune make config and specifically set IPV6 support before building!
• Edit your /usr/local/etc/rc.d/openfire to allow for a different java vm to be used:

  --- /usr/local/etc/rc.d/openfire.bak 2008-05-02 10:22:16.000000000 +0200
  +++ /usr/local/etc/rc.d/openfire 2008-05-02 10:23:00.000000000 +0200
  @@ -20,6 +20,9 @@
  # Set it to java home directory.
  # openfire_javargs (args): Set to -Xmx256M by default.
  # See java -h for available arguments.
  +# openfire_java_home (path): Set to /usr/local by default.
  +# Sets JAVA_HOME before calling java
  +# See javavm(1)
  
  . /etc/rc.subr
  
  @@ -34,6 +37,9 @@
  : ${openfire_libdir:=/usr/local/share/java/classes}
  : ${openfire_home:=/usr/local/share/java/openfire}
  : ${openfire_javargs:='-Xmx256M'}
  +: ${openfire_java_home:=/usr/local}
  +
  +export JAVA_HOME=${openfire_java_home}
  
  pidfile=/var/run/${name}.pid
  
  

  Hopefully the openfire ports maintainer will apply this patch, or offer a similar solution in a forthcoming release.
• Set openfire_java_home in your /etc/rc.conf:

  # Start openfire, make sure to use an IPv6 enabled java engine
  openfire_enable="YES"
  openfire_java_home="/usr/local/jdk1.6.0/"   # or your local variety

• Verify that both IPv4 and IPv6 are being used. Allow openfire a few seconds to bind to the various interfaces en then use sockstat to verify if tcp4 and tcp6 are in use:

  # sockstat | grep openfire
  openfire java 12742 27 stream (not connected)
  openfire java 12742 29 udp46 *:10020 *:*
  openfire java 12742 30 tcp46 *:7777 *:*
  openfire java 12742 31 tcp6 ::1:60235 ::1:60234
  openfire java 12742 33 tcp46 *:5229 *:*
  openfire java 12742 35 tcp46 *:5269 *:*
  openfire java 12742 45 tcp46 *:9990 *:*
  openfire java 12742 49 tcp46 *:9991 *:*
  

• Don't forget to block ::ffff:0:0/96 traffic on your network

 Some Tweaks

In the DNS I pointed the SRV records to a host with both an IPv4 and IPv6 address, something like:

_xmpp-client._tcp.jabber.secret-wg.org. 300 IN SRV 0 0 5222 jabber.secret-wg.org
jabber.secret-wg.org. 3600 IN A 213.154.224.48
                      3600 AAAA 2001:7b8:206:1:0:1234:be21:e31e

It turns out that with the clients I tried (iChat and Adium) I was not able to connect to the server while being connected to an IPv6 only network. When specifically connecting to the server by entering jabber-6.secret-wg.org (with AAAA RRs and without A RRs) things work like a charm.

Note also that you have to generate a certificate with a number of alt names: jabber.secret-wg.org *.jabber.secret-wg.org, jabber-6.secret-wg.org, and *.jabber-6.secret-wg.org. Create an openssl configuration file with information similar to the following, create a certificate request and get it signed with for instance cacert.

commonName = Common Name (eg, YOUR name)
commonName_default = jabber.secret-wg.org
0.subjectAltName = Subject altname
0.subjectAltName_default = DNS:*.jabber.secret-wg.org
1.subjectAltName = Subject altname
1.subjectAltName_default = DNS:jabber-6.secret-wg.org
2.subjectAltName = Subject altname
2.subjectAltName_default = DNS:*.jabber-6.secret-wg.org

[Edited to clarify a few points on April 30]

[Edited to add the Howto section on May 2]

[Edited to add the Some Tweaks section on May 7]

This years Christmas I decided to live up to the Duck Dogma ("Whenever you see Duck, eat it!") and made Confit de Canard.

Confit is a means of preparation where one starts with salting  the meat and then cook it gently, drowned in fat. 

Duck has the property to turn dry when prepared, you can prevent that by making sure the meat does not boil.

When roasting the meat that can be prevented by roasting it on a high temperature so that it is sealed by its own crust, and then leaving it on a relatively low fire until its done. 

The alternative way of preparing is to seal the meat in fat and slowly let it simmer. I have been told that can prepare beef at about 40 degrees Centigrade as long as you keep it at that temperature for a few hours, never tried it though.

I prepared the confit for 9 persons, so I bought myself 18 legs and 5 cans of goose fat.

I rubbed the legs with salt, crushed pepper and pimento. This is something that I intend to improve on the next time I prepare this. Then I plan to salting the legs by marinade them in a salt solution for a day or so.

Arrange the legs in a casserole and cover with goose fat. Use sufficient fat to make sure the legs are covered when the fat is melted. It took me exactly 5 pots of 0.5 liter.

 For taste add a few cloves of garlic, a few onions and a few leaves of laurel. 

Put this in your oven, temperature around 100 degrees centigrade so that the meat itself is at about 90 degrees. Leave this simmer for about 3 to 4 hours. That is all, real easy, cannot fail. 

By the way, a pot of goose fat of 0.5 liter costs about 4 Euro, I've never spend so much money on grease. But fortunately its great fat to prepare potatoes in.

Nick McGrath, head of platform strategy for Microsoft U.K., was surprised by the incident.

"In the demonstration we saw, it was both enlightening and frightening to witness the seeming ease of the attack on the (Windows) computer," said McGrath. "But the computer was new, not updated, and not patched."

The first sentence makes one wonder on which planet has this man been hiding. The second sentence makes me wonder how machines are sold other than new, not updated, and not patched.

From The RIPE 55 Secret Working Group Report

a long long time ago
i can still remember
when my laptop could connect elsewhere

and i tell you all there was a day
the network card i threw away
had a purpose - and worked for you and me....

But 18 years completely wasted
with each address we've aggregated
the tables overflowing
the traffic just stopped flowing....

And now we're bearing all the scars
and all my traceroutes showing stars...
the packets would travel faster in cars...
the day....the routers died

Chorus (ALL!!!!!)

So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we'd better give it a try
I suppose we'd better give it a try

Now did you write an RFC
That dictated how we all should be
Did we listen like we should that day

Now were you back at RIPE fifty-four
Where we heard the same things months before
And the people knew they'd have to change their ways....

And we - knew that all the ISPs 
Could be - future proof for centuries

But that was then not now
Spent too much time playing WoW

ooh there was time we sat on IRC
Making jokes on how this day would be
Now there's no more use for TCP
The day the routers died...

Chorus (chime in now)

So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we'd better give it a try
I suppose we'd better give it a try

I remember those old days I mourn
Sitting in my room, downloading porn
Yeah that's how it used to be....

When the packets flowed from A to B
via routers that could talk IP
There was data..that could be exchanged between you and me....

Oh but - I could see you all ignore
The fact - we'd fill up IPv4

But we all lost the nerve
And we got what we deserved!

And while...we threw our network kit away
And wished we'd heard the things they say
Put all our lives in disarray

The day...the routers died...

Chorus (those silent will be shot)

So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we'd better give it a try
I suppose we'd better give it a try

Saw a man with whom I used to peer
Asked him to rescue my career
He just sighed and turned away..

I went down to the net cafe
that I used to visit everyday
But the man there said I might as well just leave...

And now we've all lost our purpose..
my cisco shares completely worthless...

No future meetings for me
At the Hotel Krasnapolsky

and the men that make us push and push
Like Geoff Huston and Randy Bush
Should've listened to what they told us....
The day...the routers....died 

Chorus (time to lose your voice)

So bye bye, folks at RIPE 55
Be persuaded to upgrade it or your network will die
IPv6 just makes me let out a sigh
But I spose we'd better give it a try
I suppose we'd better give it a try

Words and performance by Gary Feldman

Ik ben er uit. Ik hoef niet bij het republikeins genootschap. Ik noem mezelf:

Gedoogmonarchist 

 What is the name of the debating trick that starts with making wide sweeping statements about the community of your opponent, like in:

Our 61st Febember blog post on Chocolate Cookies has generated significant attention. It is gratifying to see culinary experts like Cookie Monster respond. Not so gratifying is that Cookie Monster's response reveals that even experts in pastry can fail to understand the dietary implications of the recipes they work with daily. This has been a longstanding problem in the culinary community.

 This video contains an expose by Nate Harrisson about the "Amen Break". I did not know about the "Amen Break" as a concept and this video is an eyeopener. A good piece of music history and theory that, when you are only remotely interested in the history of modern music, you should listen to.

Nate Wilson uses the history of the Amen Break to make an elloquent argument about "innovation" in arts and culture being stiffled by to strict copyright rules.

Well worth 18 minutes of your time. One remark: this YouTube content is radio, not video.

 For those who do not know what the Amen Break is here follows the first paragraph of the Wikipedia lemma:

(usually pronounced //ɑ:'mmɛn/) was a drum-solo performed by Gregory Sylvester "G.C." Coleman. The "Amen Break", "Amen" or imitations thereof, are frequently used as sampled drum loops in hip hop, jungle and drum and bass music. It is 5.20 seconds long and consists of 4 bars of the drum-solo sampled from the song "Amen, Brother" as performed by the 1960s funk and soul outfit The Winstons. The song is an up-tempo instrumental rendition of an older gospel music classic. The Winstons' version was released as a B-side of the 45 RPM 7-inch vinyl single "Color Him Father" in 1969 on Metromedia (MMS-117), and is currently available on several compilations and on a 12-inch vinyl re-release together with other songs by The Winstons.

You probably thought this was about an open source license. (These are probably not even Gnus, but I know more about GPL than about African animals.).

My brother in law gave me a late birthday present: The latest Beasty Boys album: The Mix-UP. 

I have had a weak spot for the Beasty Boys for many years. I am not particularly fond of their rap style, its non melodic and almost old-school-cliche they do have 'balls'. Their "Get it together" from the 1994 album "Ill Communication" is one of my all time favorite Rap tunes. The Boys seemed to have managed to merge Rock and Roll and Rap in a credible and sustained way.

 Il communication lead to "The Sound from Way Out", an instrumental album that I enjoyed listening to with great pleasure.

 I was a bit surprised to find the text "Their First-Ever Full Album of All-New Instrumental material", obviously this fine marketing text needs to be close read to understand that its the first album with exclusive new material, in contrast to the Sound from the way out, that contained material from Ill Communication. Anyway, the marketeers have not spoiled the pleasure.

The sound of The Mix-Up is remarkably similar to the sound of the Sound from the way out. It seems (probably not by accident) that not much care have been taken to production value; 8-track, bedroom recordings is  my first impression. The seemingly low production  is the charm of the album; clean drum sounds, Hammond organ, wah-wah guitar, and bongo. Melodic music, with strong Bass and Guitar riffs and almost trivial melodies. Like the music that folk from the neighborhood are playing in the local community center.

To me the charm of the album is that it sounds like the music that I would like and could technically play. A couple of guys making fun without pretense, it is inspiring, and it comes close to what I think what Rock and Roll is all about.

EDITED July 12 2007

The text below is an update from the original post (June 18, 2007), that original post turned out to contain a few errors.

We have an asterisk server installed back at work and for the teleconferencing purposes I got myself a  SNOM300 SIP phone. I configured the phone to do all its NAT magic using STUN and  tested that with my  linux based homebrewed NAT box.

That worked, but the setup did not migrate to a NATted network behind my new Speedtouch 780.

Turns out that in order to use SIP behind a Speedtouch 780, that has a SIP aware application level gateway that does all kind of weird tricks to your packets. 

Having configured your SNOM to find its way through a NAT using Stun and the ALG in the Speedtouch does not work well, and generates weird timing issues that manifest themselves as 'Authorization error" in the Sytem Information panel of the SNOM phone.

The degug output on asterisk (connect using asterisk -rc and use "sip set debug") shows something of an explanation when following the SIP dialogue.

After the first registration attempt the server sends back a 401 Unauthorized message with all the parameters needed for proper authorization, including a so called 'nonce'

<--- Transmitting (NAT) to <public-ip>:52899 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 
(...skip...)
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3d58a314"
Content-Length: 0

The response to that reply is a new request from the client, without any authentication info. And the reponse from the server is again a 401 reply, with a new nonce...

<--- Transmitting (NAT) to <public-ip>:52896 --->
SIP/2.0 401 Unauthorized
(... skip ...) CSeq: 2 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1aa0547a"
Content-Length: 0

Only at the 3rd try the client registers with the authentication code... but it uses the nonce that was returned for the first request

<--- SIP read from <public-ip>:52899 --->
REGISTER sip:nlnetlabs.nl SIP/2.0
(...skip...)
CSeq: 3 REGISTER
Max-Forwards: 70
Contact: ;q=1.0;flow-id=1;+sip.instance="";audio;mobility="fixed";duplex="full";description="snom300";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"(...skip...(...
(...skip...)
Authorization: Digest username="username",realm="asterisk",nonce="3d58a314",uri="sip:nlnetlabs.nl",response="somehexcode",algorithm=md5Expires: 3600
Content-Length: 0

At that moment the Asterisk debug output will show some critical information

<------------>[Jul 11 12:01:48] NOTICE[89797]: chan_sip.c:8167 check_auth: Correct auth, but based on stale nonce received from '"username" '

What is probably relevant is that you see this happen when you turn on "Stun" and that the frequency of the registration attempts is correlated to the Stun interval you configure in the NAT settings for a the identity on your SNOM phone. Also the port on which the dialogue happen jumps for each Cseq.

After seeing this I've tried a number of permutations of settings, on the snom phone I tried all sorts of timing parameters and in the asterisk configuration I turned the NAT settings on and off. All with variable results.

Turns out that one can turn off the SIP ALG in the speedtouch 780, which solves the problem. You have to use the command line interface of your speedtouch. The CLI reference guide is available on-line.

 The magic words are: 

{Administrator}[connection]=>appconfig application=SIP SIP_ALG=disabled

NB: I have not been able to find a way to tell if the SIP_ALG is enabled or disabled using appinfo or any other command in the CLI, but I have not really been looking hard.

As soon as the SIP application level gateway has been disabled you are in business as long as:

• You configured NAT=yes for this particular user in your Asterisk's sip.conf
• You have configured a stun server in the NAT settings (under the identity settings) on your SNOM phone.

In other words. Do not rely on the intelligence of the ALG in the speedtouch modem, use 'classic' nat traversal. The meta problem here seems to be that all components in the chain try to apply their own hacks to traverse through the NAT and they do not really work nice together.

 One of these days I have to figure out if I can make the SNOM, the SpeedTouch, and the Asterisk server run over IPv6 (I hear evil laughter somewhere, because AFAIK at least two of these components will not work on IPv6 natively yet).  Life would be good if the ADSL modem would be able terminate a V6 tunnel,   do IPv6 route advertisements or DHCP6 and would not be using silly NAT tricks.

The benefit of this particular setup is that the RTP traffic from the phone will terminate at the Asterisk server, that will therefore act as a natural IPv6/IPv4 application gateway.

Keywords: NAT, Speedtouch 780, SNOM300, SIP, Asterisk