Published on , commented on March 10, 2023
IPv6 Static Addresses and Renumbering
The proponents of Network Prefix Translation for IPv6 (NPT66) usually claim it’s required for one of the two reasons: to implement multihoming without BGP (valid) and to avoid renumbering inside network(s) when the ISP assigns you a new IPv6 prefix. Let’s focus on the renumbering claim today.
A lot of IPv6-focused enterprise engineers have long advised medium-to-large networks to get their own IPv6 address space. Greg Ferro compiled a long list of good reasons to do that, and having your own PI space is not overly expensive anyway – 50€ per year in RIPE region.
Network Renumbering
There are two reasons you might have to renumber your IPv6 network (assuming it’s using public IPv6 addresses like it should):
- You’re using DHCP prefix delegation with your ISP;
- You’ve been assigned a static IPv6 prefix but decided to change ISPs (or your ISP decided they have nothing better to do than to annoy their customers).
Most hosts are renumbered automatically if you use SLAAC (it might take a while, so if you’re renumbering your static IPv6 prefix take advance precautions like lowering RA prefix lifetimes), configurations of layer-3 forwarding devices (routers, layer-3 firewalls) and the hosts with static IPv6 addresses have to be changed manually.
Assuming you have a small network with a single layer-3 device (that also acts as a firewall), you can usually perform all renumbering automatically based on IPv6 prefix delegated via DHCPv6 (checking whether your edge router supports that might be a good idea if you’re buying new gear).
If you have more than one layer-3 device in the network, you’ll probably have to do the renumbering process manually (one would hope that vendors would eventually implement hierarchical prefix delegation, but I haven’t seen it implemented yet), but even there a bit of planning goes a long way – general prefixes make life easy for Cisco IOS users (Junos has a regex search/replace that you can use to replace patterns, including parts of IPv6 addresses, throughout the configuration).
Server Renumbering
Automatic IPv6 host renumbering works only if the hosts use SLAAC. Hosts with static IPv6 addresses have to be renumbered manually, but even there you could use Unique Local Addresses (ULA – RFC4193) to avoid most of the renumbering hassle – assign a global IPv6 prefix and an ULA prefix to every subnet, use static ULA addresses for your inside servers, and use ULA addresses for all internal communications.
Servers that are not reachable from the Internet don’t have to have static public IPv6 addresses – they should have a static ULA address that their clients can use, and a dynamic public IPv6 address they use to access the Internet if needed (example: software patches).
But what about publicly reachable servers? Technology doesn’t provide a good answer here and so we enter the realms of layer-10 (religious layer). Some people claim it makes perfect sense to have your own public servers even in networks that are so small they can’t justify paying for their own IPv6 address space ... and thus invoke the magic of NPT66 to avoid server renumbering (because it’s so hard to renumber the only server you have in your organization after manually changing its public DNS entry whenever you decide to change your ISP).
I would rather spend $4.95 a month and have a server hosted by someone with reliable infrastructure, which might also increase my web site availability, but that’s just me.
Summary
Properly-designed IPv6 networks will use public IPv6 addresses in combination with ULA addresses (when needed). Get used to it. If you’re big enough, get your own IPv6 address space; if you’re too small, buy networking gear that supports easy renumbering.
In my personal opinion, the need for NPT66 to avoid server renumbering in single-homed networks without their own PI IPv6 address space is a totally bogus claim. Organizations this small should not have public-facing servers – web hosting is cheap enough these days.
If you’re an IT geek who wants to be able to hug all his servers, that’s perfectly fine with me – just don’t complain if you have to take care of them every now and then. I prefer to have a web site that keeps running even when I’m on vacation.
More Information
If you’ve just started considering the impact of IPv6 on your network, my Enterprise IPv6 – The First Steps webinar will get you started. Building Large IPv6 Service Provider Networks webinar will give you numerous design guidelines that are also applicable to large enterprise networks (IPv6 for Enterprise Networks is also a pretty good book).
A few more IPv6 webinars are planned for this year and you can get access to all of them with the yearly subscription.
2012-04-04 11:30 GMT: Added information from Sebastian's comment — Junos search/replace functionality.
Security-by-obscurity with the IPv4 NAT is a "good-enough" arrangement for small networks, where there is no need for the big bad Internet to make direct contact with all the unpatched office PCs with RDP enabled on them.
What's in your opinion the best way of achieving the same with IPv6?
P.S. I do sort-of buy the "the apps will work better when all hosts cat talk to each other directly"; however when it comes to choosing between the convenience of being able to run crappily designed protocols/apps and providing a however basic level of isolation from the raw Internet without additional effort, I choose the second without batting an eyelid.
replace pattern "2001:db8:1:" with "2001:db8:2:"
All internal devices could go through a proxy (how it is done today in a lot of companies) to get to the internet.
...that is, if they have it. Just checked one of those - Apple AirPort Extreme, doesn't have one. Has DHCP, has NAT. No firewall. I suspect situation may be not much better for others. Firewall is tricky, compared to NAT. And more resource-intensive.
Sigh.
i have seen some NAT "magic" done at the loadbalancer or stateful firewalls because of asymmetric routing behind that barrier. otherwise the returning packet would not go through the same firewall and would be dropped.
How would you solve this problem with IPv6?
thanks!
BR,
Gernot
Load balancing in IPv6 works exactly the same as in IPv4. Nothing you can do to change it.
You might make it more anycast-ish with LISP (and lose some of the fast failure detection and dynamic balancing capabilities), but the problem is that it would work well only if you have enough ITRs.