The Problem
It happens to the best of us. I administer an Internet-facing server for a client, who has native IPv4 connectivity, and IPv6 connectivity via 6to4. All was going well, until one day, the owner needed more IPv4 addresses. So we contacted their ISP (Comcast) and upgraded our /30 block (one IPv4 address) to a /29 block. That’s all and well, except:
- The new /29 subnet does not contain the /30 subnet.
- Comcast could not give a transition period. As soon as they pushed the config file to the gateway, it would reboot, instantly deactivating the old /30 and activating the new /29.
The Ideal Solution
Needless to say, this is a bit of a problem. In a perfect world, Comcast would activate the /29 alongside the /30, keep both up for a few days, and then shut down the old /30. That would give us enough seamless transition time, so our clients and customers would see no interruption of service.
The Accepted Solution
This solution is partly drawn from experience, and partly from a “Gee, in retrospect, I should have done that” position. For the rest of this post, I will use the following conventions:
- 192.0.2.1/30
- The old IPv4 address and subnet, in CIDR notation.
- 192.0.2.100/29
- The new IPv4 subnet.
- 2001:db8:0:1::1
- The old IPv6 address. (Yes, I know this isn’t in the 6to4 subnet, 2002::/16. I’m opting to use the documentation prefix instead.)
- 2001:db8:0:1::100
- The new IPv6 address.
- example.com
- The server’s DNS name.
The following post also assumes that you are running your DNS on BIND 9. If you don’t, then the specific DNS changes neededare left as an exercise for the reader; fortunately, this isn’t anything complicated.
1. Notify your users.
Firstly, if your site has any sort of announcement system, like an RSS feed, or a login page, put up a notice warning users of downtime. At the very least, inform them that there will be downtime, and have them plan to not use your site immediately after the IP address changeover. This may seem like a no-brainer, but even the most hardcore of nerds working for a company shouldn’t forget about customer service.
Because our site is tech-oriented, I also included directions on how to reach our site if it refuses to load (that is, having the user change their hosts file). A bit overkill, but I like to cover all bases.
2. Decrease your zone’s TTL.
Secondly, what you want to do is update your DNS records. Two things need to be addressed. The first is to change your zone’s TTL down to a smaller value. Change this to the maximum amount of downtime that is acceptable. They keep their DNS TTL at 86,400 seconds (one day). For this, I’d recommend changing it to 10,800 seconds (3 hours). Change your SOA record accordingly:
1
2
3
4
5
6
7
8
| $TTL 10800 ;change this to 10,800 seconds (three hours)
www.example.com. IN SOA authoritative.dnsserver.com. youremail.example.com. (
2009102501 ;Serial — increment this, as always
3h ;Refresh — change this to "3h" (10,800 seconds)
1h ;Retry
4w ;Expire
3h ;Negative caching TTL
) |
Lower TTL values will cause your authoritative nameserver to get a great deal more traffic. If you outsource your DNS hosting like this client does, that may anger your DNS host.
3. Add your new IP addresses to your zone
The second thing to do is update your zone files to include both the old and new addresses. If you have both IPv4 and IPv6 connectivity, then this means that your zone file will have four IP addresses. Bear in mind the following facts about DNS when a host has more than one IP address:
- Generally, DNS servers will shuffle the records, and return the IP addresses in a different order every time.
- Generally, a client will pick a random IP address out of the list; A and AAAA records don’t have a priority value like MX and SRV records do.
- Almost always, a client will try another IP address if the first fails.
Thus, with two IP addresses in the zone file, your clients will connect quickly about 50% of the time during the DNS transition. This is a very simple change:
1
2
3
4
| www.example.com. IN A 192.0.2.1
www.example.com. IN A 192.0.2.100
www.example.com. IN AAAA 2001:db8:0:1::1
www.example.com. IN AAAA 2001:db8:0:1::100 |
Save your zone file, sign it (if you use DNSSEC), and do an
to reload the zone and notify your authoritative nameserver. Remember your old TTL value? Wait at least that much time before proceeding with the IP changeover, especially if you have international users.
4. Edit your server’s IP configuration.
You’re going to have a little downtime, and a period of confused users. But keep thinking ahead. Now, log into your server (preferably over a physical console) and update its IP configuration. On Gentoo Linux, this consisted of:
- Editing the /etc/conf.d/net file, to include the new IP information:
1
2
3
4
5
6
7
| config_eth0=(
"192.0.2.1/30"
"192.0.2.100/29"
"2001:db8:0:1::1/64"
"2001:db8:0:100::1/64"
# Also include your other IP addresses here.
) |
- Because this server is also an IPv6 router for the local subnet, radvd is announcing the IPv6 prefix to the private IPv4 subnet. Adding a prefix to the /etc/radvd.conf file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| prefix 2001:db8:0:1::1/64 {
AdvValidLifetime 86400;
AdvPreferredLifetime 86400;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
prefix 2001:db8:0:100::1/64 {
AdvValidLifetime 86400;
AdvPreferredLifetime 86400;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
}; |
Save and reload radvd.
- Checking the DHCP server settings. DHCP may not be affected, but DHCPv6 will definitely be affected by the changing subnets.
- If you have the fixed IP address recorded anywhere else, make sure you add the new IP addresses! (I can’t help you on this one, but they did have the IP address specified in: (1) Postfix’s /etc/postfix/main.cf file, with the smtp_bind_address and smtp_bind_address6 directives, (2) switch configurations, and (3) IP address filters in Apache for their Intranet applications.
Reboot the server if necessary. If you can, reboot it anyway — even you, Linux users.
5. Change your IP address.
The big moment has come. Contact your ISP and have them perform the changeover. This resulted in about a minute of downtime as their cable modem received the new settings and rebooted. As soon as you can afterwards:
- Remove the old IP addresses from the zone file. Increment the serial, reset the TTL, save, sign, and rndc reload.
- Remove the old IPv6 subnet from /etc/radvd.conf.
- Reboot some workstations and check basic connectivity to and from the server and the IPv4 and IPv6 Internet. Then go offsite and try to reach the server with the DNS name and new IP addresses.
- Be prepared to answer phone calls and emails from clients who can’t reach the site.
I hope that this helps anyone else in this predicament. I still don’t know why Comcast couldn’t offer a transition period, especially to a business customer. Regardless, the changeover for this client went very smoothly, and there were no issues reported. Everything is now running just fine, and they’re making use of their new — and limited — IPv4 address space.
