It amazes me when a $50 device supports ssh tunelling! I wanted to run the web interface on a MikroTik router I’d just installed. Command line access is all very well, but for a lot of stuff, the web interface is a lot quicker (and less error prone).
Here is how I got my MikroTik RB951-2n working with Internode’s native IPv6 service over ADSL. I did not nut all this out myself; there was googling involved, but nothing I found was complete and many articles assumed I knew more about MikroTik’s RouterOS than I did. That said, all mistakes here are my own :-)
In a mailing list I frequent, the conversation turned to tunnels as a means of getting IPv6 access. A personage of note who shall remain nameless here said:
> IPv6-over-IPv4 tunnels are perhaps worse than not doing it at all.
I took issue with that statement, and here, lightly edited, is my response:
In the past couple of days I have been configuring bunch of MikroTik routers. The configurations differ, but they all have a few things in common, and I wanted to record those things in a separate file as variables. My idea was that I could then include the separate file in lots of different scripts using
/import, so that changes to these common details would only need to be made in one place.
It turned out not to be as simple as I thought!
Warning: Australian-only content :-)
Now that the Coalition has finally released its NBN policy (here’s a copy) here’s my take on it:
Fibre has a future. Copper has no future. Why is that something that people find so hard to understand?
IPv6 source address selection must be very irritated; destination address selection gets all the press coverage.
This article will start to redress the balance, by talking about what IPv6 source address selection is, why it is needed, and how it works. If you want the nitty-gritty, check out RFC 6724 (which obsoletes RFC 3484).
NAT came into existence because of IPv4 address scarcity. With IPv6, that reason disappears. So, if we no longer need to multiplex addresses, should we retain NAT?
So you have an application. It was written (as far as you know) without IPv6 in mind, and now it has to work with IPv6. How hard is that going to be? Well, it depends on the application. Most of the following is not really Java specific (but some of it is).
If you read the doco (like “
man gai.conf“) you would be forgiven for thinking that the contents of
/etc/gai.conf controlled source and destination address selection in IPv6. You would be wrong.
Most of the problems you are likely to run into when trying to get the Gogo6 client up and running can be fixed using common sense – i.e., making sure that the various configuration items are properly set. One biggy that is a bit trickier is the “missing virtual tunnel adapter” problem, but when installed correctly, and with the various user-settable parameters set correctly, the Gogo6 client generally Just Works.