Changing network prefix with new ISP

[Kizaki]

Hi there,

Is there an easy way to change the network prefix for all the routers and devices when moving to a new IPv6 provider?

For example, is it possible for the host portion of the IPv6 address to remain static, while keeping the network portion of the address dynamic. With some devices, such as some of our copiers, I had to assign up static IPv6 addresses for them to work.

How would one come about avoiding the problem with renumbering all the DNS AAAA records?

Is it also possible to renumber the addresses on a routing table on all the routers quickly?  I am using OSPF for our IPv4 routes.  Our IPv6 routes are still statically set for now.  Is there any tricks that I could use with OSPF or even the static routes, to change the network portion of the address without retyping them all?

Unlike IPv4 I don't think it is possible to set up NAT with IPv6.  The problem with this, is that it puts us at the mercy of our ISP when it comes to renumbering.  I can see this becoming a massive amount of work and a big deal to an organization that has more than just a few routers. I would really like to avoid this problem when our IPv6 network becomes much larger.  Are there solutions worked out for any of this? 

Thanks,
Kizaki

[broquea]

Well, in a RA world, the host portion is static as it is based on that machine's MAC address. The network portion is the first 64bits of the address. So if you move from one /64 to another, only the first 64bits change.

For rDNS zonefiles, like let's say BIND, you can simply change the references to the network 64bits from old to new, without retyping all the PTRs (assuming last 64bits are the PTR).

With forward, you'd have to change all entries that use that network prefix, and depending on how your dns is managed, could be simple search and replace like sed, regex, etc.

[cholzhauer]

i went through this a couple of weeks ago and unsderstand your concern.  i couldnt come up with an automated way to do this, so i was left to do it all by hand.  it took me the better part of the morning to finish everything, and even then it wasnt really completed until i could reboot all of the hosts.  RA does make it easier, but still not painless

[jimb]

Even in a DHCPv6 world, you could just change the prefix and all your host numbers could stay that same.  Of course, the same could be true of IPv4 publics or privates of the same prefix length.  But IPv4 publics inside just isn't realistic in today's world anyway. 

The ISP change is definitely one situation where IPv4/NAT situation is easier than IPv6, since you don't have to renumber your inside hosts. 

But it's not so bad, if you plan and do it right.  If you're using auto configuration or DHCPv6, and transitioning between ISPs, you can have both ISPs connected at once during transition, and your hosts would slowly change IPs/prefixes as leases ran out, etc, and start using the new ISP with no interruption in internet connectivity.  You could configure all your networking equipment ahead of time to have both old and new prefixes on its interfaces, have routing for the new pref set in parallel for both, etc.  You could also do RDNS ahead of time and in parallel with the old prefix. 

For servers, you'd likely do the same thing as the routers/networking equipment, adding the new IPv6s to each interface so that it has both the old and new prefixes simultaneously.  That way, you could change forward DNS entries one at a time if need be, and the servers would still be reachable by both addresses during the transition, TTL timeouts of DNS entries, etc.  Obviously you'd set your TTLs to very low numbers in anticipation of the transition.  You'd probably have to bounce some of the servers, or services running on those servers so they listen on both IPs.

Once everything was transitioned, you could start deleting the old statically configured prefix IPs from all your equipment.

The only real bugaboos I see in doing things like this are things such as licensing based on IPs (which is dumb to begin with, but I think some products still do it), which will create re-licensing chores.  And possibly other stuff such as MS Active Directory and stuff like that, which I know is very dependent on DNS.  But I'm not really familiar enough with that "world" to know how painful IP changes are.  Perhaps it's simple.  And of course, if you use statically configured IPv6 addresses in configuration files (/etc/hosts, etc) or scripts instead of DNS names, these will all need changing too.  Which is why one uses DNS names instead where possible.   :P

[cholzhauer]

It wasn't all that bad to change RDNS entries in AD/DNS...you just have to delete the old entries and dump in the new ones (copy/paste works fine for this)

Like I mentioned, the only gotcha I had was the fact that I had to reboot Windows machines before they would use the new IPv6 tunnel (after the old one was taken off line)

[snarked]

You should also consider all your initialization files and their design.

For example, with Linux (which I use on some systems), I set my IPv6 Prefix for a machine as a kernel parameter that gets passed as an environment variable to my initialization scripts.  Therefore, to change networks, all I have to do is change my "/etc/lilo.conf" file and reboot.  (Of course, I have to make changes in the DNS for the system to be reachable from others at that point).

I severely limit the places where I have to use an IPv6 address, as opposed to a hostname - so as to reduce the number of changes.  I only have 9 files (including "/etc/named.conf") other than DNS zone files to change.  Everything else on the system either picks up the address from the environment variable or uses hostnames.

[bdowning]

You can also allocate parallel IPv6 "unique local" addresses (fc00::/7) for your network.  That way you can have stable addresses to put into any configuration files that are hard to automatically update when your ISP changes.  Each machine will have both a public IP (which will change with your ISP) and a local IP (that won't).

You still need to touch all the routers and DNS for your public IPs, but doing the above means that each machine also has an address that will never change.

See RFC 4193 for how to create these addresses.

[snarked]

I thought that site local addresses (FC00::/7) were depreciated and the RFC withdrawn?

[jimb]

AFAIK, Site Unique (fc00::/7) weren't deprecated, Site Locals (fec0::/10) were.

[snarked]

OOps!  You're right.  Maybe I need to fully wake up before I post.  ;-)