listen="*, [::]"With that done and the service restarted my email if now available over IPv6 too. This should become the default most likely.
Thursday, 26 July 2012
IPv6 and dovecot
For my mail server I use dovecot. By default this only binds its sockets in IPv4. It is however trivial to enable binding of IPv6 as well. Simply change the "listen = *" entry in its configuration (/etc/dovecot/dovecot.conf) as below:
IPv6 and weechat
With my bip proxy IPv6 enabled it is time to look at my IRC client. I am a 'weechat' user so that is my target. It seems that weechat has some support for IPv6 via its 'ipv6' option on the server configuration block. You can set this option for connection 'freenode' as below:
/set irc.server.freenode.ipv6 yesThis certainly switches the connection over to IPv6, but it does not seem to fallback to IPv4 automatically. Some additional support will be required to handle this, though the changes look minor. I guess we can call this half enabled.
Thursday, 12 July 2012
IPv6 dual-stack listeners?
As alluded to in my previous post "IPv6 and bip" when a service creates its network endpoint as an IPv6 socket it is actually able to communicate with both IPv6 clients and IPv4 clients interchangeably. But how does this work?
This compatibility mode is defined in one of the foundation Request For Comments (RFC) documents, specifically RFC3493 which defines how the socket() interfaces should behave with respect to IPv6 (see section 3.7 for the gory details). This defines a reserved area of IPv6 address space which maps 1:1 to IPv4 addesses. Essentially the IPv4 address may be translated into a unique reserved IPv6 address by concatenating the 0:0:0:0:0:FFFF prefix with the existing IPv4 address. As this address is unique the underlying socket implementation can directly infer the correct physical protocol to use for this connection from the address alone, allowing connections to safely coexist.
The great thing about this compatibility mode is it works for any socket, server or client. This allows an application to support only IPv6 and yet remain compatible with addresses of either type. We no longer have to care which they are, nor does a service have to bind sockets to each protocol and handle the complexity that entails. Magic.
This compatibility mode is defined in one of the foundation Request For Comments (RFC) documents, specifically RFC3493 which defines how the socket() interfaces should behave with respect to IPv6 (see section 3.7 for the gory details). This defines a reserved area of IPv6 address space which maps 1:1 to IPv4 addesses. Essentially the IPv4 address may be translated into a unique reserved IPv6 address by concatenating the 0:0:0:0:0:FFFF prefix with the existing IPv4 address. As this address is unique the underlying socket implementation can directly infer the correct physical protocol to use for this connection from the address alone, allowing connections to safely coexist.
The great thing about this compatibility mode is it works for any socket, server or client. This allows an application to support only IPv6 and yet remain compatible with addresses of either type. We no longer have to care which they are, nor does a service have to bind sockets to each protocol and handle the complexity that entails. Magic.
Tuesday, 10 July 2012
IPv6 and bip
As a keen IPv6 advocate I have been playing around with the various applications and services I use on a regular basis and have been trying to enable IPv6 use; today it was my IRC proxy 'bip'. bip turns out to be very simple to convert indeed. Simply requesting bip bind on the IPv6 unspecified address (::) triggers it to switch to IPv6 and (through the magic of the Linux dual-stack IPv4 handling) this enables either IPv4 or IPv6 clients to connect to the proxy.
To change the default bind address in bip simply change the ip configuration in your .bip/.bip.conf to use the IPv6 unspecified address as below:
To change the default bind address in bip simply change the ip configuration in your .bip/.bip.conf to use the IPv6 unspecified address as below:
ip = "::";
As simple as that. Probably the default behaviour of bip should be to bind :: (IPv6) and on failure bind 0.0.0.0 (IPv4).
Wednesday, 20 June 2012
Ubuntu Plus One
In the Precise development cycle a new archive oriented team was trialled, the Plus One team. This team was created to help keep the archive in an installable and buildable state at all times, a major driver for early testing and for a solid LTS release. The Plus One team is tasked with general house keeping for the Ubuntu archive. for finding issues such as build failures or packages which are no longer built from the source in the archive, and figuring out what to do with them. They are also responsible for figuring out why our images are broken on any particular day and driving resolution.
This cycle when they were looking for volunteers for the team for the Quantal cycle I was put forward to help. It sounded interesting as the work has a much broader base than my normal role, touching anything in the Ubuntu archive. I have been working with Debian packages for over 4 years, but mostly kernel related packages and they have their own quirks. This gave me a chance to branch out and solidify my Ubuntu skills, a good stepping stone to becoming a core-dev in my own right. An exciting and scary prospect.
I have been working on the Plus One team for a couple of weeks now, and all I can say is it has been a baptism of fire, have had to touch C++, C, python, ruby, perl (and more) often in the same package. Had to fiddle with autoconf, and get familiar with the multitudinous patching schemes. I have learned a healthy hatred for quilt (as it lets me lose my changes for the umpteenth time). Test built untold packages; my poor test build server is crying out for a rest after the utter pounding I have given it. For all this work we have made some progress indeed, but at this time in the cycle the breakage is building at least as fast as we club it into submission. At times it is soul destroying.
Overall though it has been a very positive experience, I have learned a huge amount about the archive and packaging in the Ubuntu world, and gained a healthy dose of respect for anyone who voluntarily maintains other peoples packages. All I can really say is a big thank you to those who look after this stuff full time, you are made of strong stuff indeed.
This cycle when they were looking for volunteers for the team for the Quantal cycle I was put forward to help. It sounded interesting as the work has a much broader base than my normal role, touching anything in the Ubuntu archive. I have been working with Debian packages for over 4 years, but mostly kernel related packages and they have their own quirks. This gave me a chance to branch out and solidify my Ubuntu skills, a good stepping stone to becoming a core-dev in my own right. An exciting and scary prospect.
I have been working on the Plus One team for a couple of weeks now, and all I can say is it has been a baptism of fire, have had to touch C++, C, python, ruby, perl (and more) often in the same package. Had to fiddle with autoconf, and get familiar with the multitudinous patching schemes. I have learned a healthy hatred for quilt (as it lets me lose my changes for the umpteenth time). Test built untold packages; my poor test build server is crying out for a rest after the utter pounding I have given it. For all this work we have made some progress indeed, but at this time in the cycle the breakage is building at least as fast as we club it into submission. At times it is soul destroying.
Overall though it has been a very positive experience, I have learned a huge amount about the archive and packaging in the Ubuntu world, and gained a healthy dose of respect for anyone who voluntarily maintains other peoples packages. All I can really say is a big thank you to those who look after this stuff full time, you are made of strong stuff indeed.
Monday, 28 May 2012
World IPv6 Launch Day -- 6th June 2012
The 6th of June 2012 is an interesting day, World IPv6 Launch Day. On this day a swathe of influential web-sites will be enabling IPv6 addresses for their services by default and not turning them off. Why is this interesting? For the most part it is not! For most people nothing should happen, things should continue working probably using IPv4, fine. For those of us with working IPv6 again nothing will change other than we will be producing more IPv6 traffic, great. It is those who have unused broken IPv6 who will start having fun, they will likely lose connectivity to the participating sites until they sort out their issues.
So why is this a good thing? This is a key step towards IPv6 adoption, and we really do not have any other choice but to adopt IPv6. Adoption will only be driven by need, and this move creates exactly that need. Such ISP and client issues need to be identified and solved, before the end users lose connectivity to even greater swathes of The Internet, those parts which only will exist on The IPv6 Internet.
For more information see: http://www.worldipv6launch.org/
So why is this a good thing? This is a key step towards IPv6 adoption, and we really do not have any other choice but to adopt IPv6. Adoption will only be driven by need, and this move creates exactly that need. Such ISP and client issues need to be identified and solved, before the end users lose connectivity to even greater swathes of The Internet, those parts which only will exist on The IPv6 Internet.
For more information see: http://www.worldipv6launch.org/
Tuesday, 15 November 2011
IPv6 at home?
The Internet has been alive with doom saying since the IPv4 global address pool was parcelled out. Now I do not subscribe to the view that the Internet is going to end imminently, but I do feel that if the technical people out there do not start playing with IPv6 soon then what hope is there for the masses?
In the UK getting native IPv6 is not a trivial task, only one ISP I can find seems to offer it and of course it is not the one I am with. So what options do I have? Well there are a number of different types of IPv4 tunnelling techniques such as 6to4 but these seem to require the ability to handle the transition on your NAT router, not an option here. The other is a proper 6in4 tunnel to a tunnel broker but this needs an end-point.
As I have a local server that makes a sensible anchor for such a tunnel. Talking round with those in the know I settled on getting a tunnel from Hurricane Electric (HE), a company which gives out tunnels to individuals for free and seems to have local presence for their tunnel hosts. HE even supply you with tools to cope with your endpoint having a dynamic address, handy. So with an HE tunnel configuration in hand I set about making my backup server into my IPv6 gateway.
First I had to ensure that protocol 41 (the tunnelling protocol) was being forwarded to the appropriate host. This is a little tricky as this required me to talk to the configurator for my wireless router. With that passed on to my server I was able to start configuring the tunnel.
Following the instructions on my HE tunnel broker page, a simple cut-n-paste into /etc/network/interfaces added the new tunnel network device, a quick ifup and my server started using IPv6. Interestingly my apt-cacher-ng immediately switched backhaul of its incoming IPv4 requests to IPv6 no configuration needed.
Enabling IPv6 for the rest of the network was surprisingly easy. I had to install and configure radv with my assigned prefix. It also passed out information on the HE DNS servers, prioritising IPv6 in DNS lookup results. No changes were required for any of the client systems; well other than enabling firewalls. Win.
Overall IPv6 is still not simple as it is hard to obtain native IPv6 support, but if you can get it onto your network the client side is working very well indeed.
In the UK getting native IPv6 is not a trivial task, only one ISP I can find seems to offer it and of course it is not the one I am with. So what options do I have? Well there are a number of different types of IPv4 tunnelling techniques such as 6to4 but these seem to require the ability to handle the transition on your NAT router, not an option here. The other is a proper 6in4 tunnel to a tunnel broker but this needs an end-point.
As I have a local server that makes a sensible anchor for such a tunnel. Talking round with those in the know I settled on getting a tunnel from Hurricane Electric (HE), a company which gives out tunnels to individuals for free and seems to have local presence for their tunnel hosts. HE even supply you with tools to cope with your endpoint having a dynamic address, handy. So with an HE tunnel configuration in hand I set about making my backup server into my IPv6 gateway.
First I had to ensure that protocol 41 (the tunnelling protocol) was being forwarded to the appropriate host. This is a little tricky as this required me to talk to the configurator for my wireless router. With that passed on to my server I was able to start configuring the tunnel.
Following the instructions on my HE tunnel broker page, a simple cut-n-paste into /etc/network/interfaces added the new tunnel network device, a quick ifup and my server started using IPv6. Interestingly my apt-cacher-ng immediately switched backhaul of its incoming IPv4 requests to IPv6 no configuration needed.
Enabling IPv6 for the rest of the network was surprisingly easy. I had to install and configure radv with my assigned prefix. It also passed out information on the HE DNS servers, prioritising IPv6 in DNS lookup results. No changes were required for any of the client systems; well other than enabling firewalls. Win.
Overall IPv6 is still not simple as it is hard to obtain native IPv6 support, but if you can get it onto your network the client side is working very well indeed.
Subscribe to:
Posts (Atom)