ip4/ip6 migration?

#1

What are considered best practices to deal with the upcoming ip4 address exhaustion? I have googled around and a lot of the dual stack recommendations of the last five years seem to be universally ignored. Will NAT save me from having to configure my bytemark virtual server for ip6? Nobody seems to know.

Bytemark advertizes ip6 support on its virtual machines which I have not taken advantage of. The checklist for doing so looks straightforward:
[ulist]
[] netstat --all -p shows ip6 listening ports for all my current services
[] the ip6 address I would get would be setup with a static line in /etc/network/interfaces (I’m running debian Lenny)
[] ip6tables needs to run in parallel with iptables but my rule set is small and easily duplicated
[] dns A6 records are unused and can safely be ignored
[*] the bind9 name server I am running supports AAAA records without a fuss — but what about bytemark’s content dns servers?
[/ulist]
But!!! my domain name registrar doesn’t seem to support ip6 glue records so is the whole exercise pointless?

It does seem this will be necessary at some point in the near future. How long I can put it off?

#2

My guess is that you will have to move to dual stack at some point, no matter how many smart NAT solutions people are coming up with. Carrier grade NAT solutions do have inherent problems which are not easily overcome (logging/traceback…). And I really don’t see the point of not taking advantage of the great service from Bytemark. Having native IPv6 is, and will always be, an advantage.

Great knowing that all your current services support IPv6, but really not necessary at this point. You may move service by service by choosing which to advertise AAAA records for (assuming that you use separate DNS names for separate services).

Bytemark has excellent documentation for Debian, so editing /etc/network/interfaces should be straight forward

You may have to give the iptables rules a thought while duplicating. Do note that icmp is even more important with IPv6 (you cannot just drop all of it, like some think they can with IPv4). And you will always have more than one local address (at least one global and one link local), for which you may want to configure rules.

A6 records are gone, yes. You’ll configure PTR records much like for IPv4. Note that (unless they’ve changed it recently) you will have to ask Bytemark for a delegation of the reverse zone. They’ll add it to your content DNS account on request, so it’s no problem. Just not automated yet.

Bytemark’s content DNS servers does support AAAA records and their example data contains examples of how to configure this.

The glue records would be nice to have, but I doubt you will have any problems without them. The only thing that won’t work is an IPv6 only resolver, but I cannot imagine anything like that existing outside lab environments anyway. It wouldn’t be able to resolve many names at all.

You can probably put if off longer than anyone thought was possible, but why?

Bjørn

#3

So, I got around to actually getting the server to actually listen on the blah:blah::10 address bytemark wants to me to use on my vm and wonder what to do with the 2^64-11 addresses they have also assigned to me. That’s a lot of address space when I really only need 1. On the order of 10,000,000,000,000,000,000 too many.

The very basic firewall is up. Converting my more complex ip4 rules isn’t necessary as I only intend to open up www (and maybe dns) ports to the ip6 world.

Next step is to learn how to set up tunnelling from home. No ip6 through my ISP.