Ok, first of all, my usual rant about something working badly.
I understand that, since IPv4 address space is considered a subset of IPv6 one (e.g., 192.168.0.3 becomes [::ffff:192.168.0.3]), when I bind on port 1234 using IPv6 wildcard address ([::], the equivalent of IPv4’s 0.0.0.0), I take control of port 1234 also for IPv4; so, when someone tries to connect via IPv4 to my server at port 1234, I get it.
But WHY, if I use IPv4 wildcard, I get the same result? Better, I get a mixed result under my debian etch: IPv6 connections are refused (and this is quite correct), but I cannot bind to the same port on the IPv6 address space, neither using the wildcard (and this too is correct, because the IPv6 wildcard would imply also all the IPv4 address space, which is instead already taken) nor using a specific IPv6 address, and this is what makes me crazy. I mean, everything solved for me by forcing the server which took the IPv4 wildcard to be someone more selective, and take only a specific IPv4 address, but the doubt remains.
And now, why did you do this? Well, my dear amavis, as I already told you, does not bind to IPv6 addresses. So I wrote a little TCP tunnel which does only and exactly this: bring connections and datas from one address to another one; in this case, listen on the IPv6 address and forward it to the IPv4. A sort of TCP router, I’d say. In attachment, the code.
BEWARE: using the TCP tunnel, there’s a slight change of semantic for refused connection. If the destination address refuse a connection, the tunnel instead accept it and immediatly drop it. Sorry, this shouldn’t cause any problem for common uses.
Posted by mattia as ipv6 at 3:04 PM CET
No Comments »
So, what’s the status of the IPv6 development nowadays? Sometimes I wonder.
I mean, these days I’m migrating services from eliot to ralph, and up to now the only one thing I’ve noticed that Amavis (based on Net::Server perl module) doesn’t seem to like at any rate binding on IPv6 addresses; MySQL doesn’t accept IPv6 connections either (there’s a Google Summer of Code project about this, but the only patch I’ve found, digging between mailing lists, no longer patches correctly current code), and so on.
I also had a plan: I have a VPN from my home server to the laptop, so I can access internal services without worries about security. I thought: if I add a radvd daemon, I can get free ipv6 connectivity. In fact this involved adding a small routing rule by hand, but it worked fine on Linux (more on that on a later article), whereas the tuntap driver under MacOS doesn’t seem to understand router advertisement packets (sent a mail to the author, so I’ll wait his response before telling you I’m sure about this).
So, nowadays it’s difficult even only to have internal network IPv6 connectivity. What a pity.
As a side note, I want to talk about a subtle distinctions between a concept present in both IPv4 and IPv6: local link address. The problem is that a person approaching IPv6 is tempted to think link-local addresses ([fe80::]) are the equivalent of IPv4 private subnets (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16). This is not true at all. Private subnets are exactly what the word says, and the IPv6 most close equivalent is site-local subnets, which as of now have been quite discouraged. Link-local addresses in IPv6 are thought to be used exactly, well, for link-local purposes (I write a protocol which checks if servers with given MAC addresses are reachable, and I use link-local addresses). Private subnets in IPv4 instead are used because
- we need NAT, and
- for security implications: bind your servers to 192.168.0.0/24 and they won’t be reachable from the outside.
Ok, for the 1), we know that with IPv6 we no longer need it, but for 2)? Well, the point is that security should not be implemented this way in the IPv6 philosophy, but by firewalls, which conceptually surely fits in. So, no more bind addresses in the IPv6 addresses. Anyway, what should stop you to use this security plus? Because of two facts:
- a link-local address has no meaning without an associated interface, since it contains no routing informations. this isn’t supported by any server I know of, and shouldn’t by design.
- if you move the server, you’re lost. if you phisically split the network, you’re lost again.
In case the point isn’t clear, link-local addresses have no informations about routing, that’s the problem. So, they seem to be a step backward from private subnets, but they are not: take into consideration that link-local addresses is get automatically. If you add a server radvd, you have full network configuration for free. Attach your computer, and start going into the web. It’s not DHCP built after the IP infrastructure, it’s almost the contrary.
So, it all seems neat and cleaner under IPv6. Bet there’ll be some sort of problems with this shift of view? :-)
Posted by mattia as ipv6 at 10:09 PM CET
No Comments »
