You’ve managed to secure the correct amount of IPv6 address space from your primary Internet provider after investing a bit of time doing an address plan (using Tom Coffeen’s IPv6 Address Planning book from O’Reilly Media of course!). You are ready to turn up your IPv6 at the Internet edge and you are pretty excited. You manage to get it all working and for fun you ping your first public IPv6 host, say 2001:4860:4860::8888 which is the open public DNS nameserver that Google maintains. It all works, high fives all around. You manage to get your firewall up and working and get basic routing and client access functioning and you are feeling pretty good about how things are progressing. You have IPv6 implemented and working while not having broken your existing IPv4. You have a successful dual-stack network now. Life is good.
Then it happens: Your boss pulls you into the office and informs you that management has several cost-cutting measures planned and one of the items identified is the Internet circuits. Some “carrier cost consulting” agency came in and sold the management team on their super-effective carrier relationships and how they can save the company big money over several years by moving carriers and therefore the company’s Internet service provider.
You start going through your checklist of items you will have to deal with. You will need to reconfigure your firewalls to change out the IPv4 NAT configurations. There are some site to site VPN tunnels and client VPN settings you will have to change. Some third-party services will need your new public IPv4 address ranges. And then it hits you. You are going to have to readdress your entire IPv6 network because the IPv6 address space you used belongs to the current service provider you have, not the new one. The IPv6 address is non-transferable and you can’t take it with you as you move providers. You panic. You start to explain the issue to your manager. They are having none of it. They state this has never been a huge issue in the past when the company changed service providers, why is it now? You explain it to them, they still don’t understand. They don’t change their mind about it. You panic more. What do you do?
You consider sending out your resume to get a new job before this change has to happen. You wonder why IPv6 is so painful. Why can’t IPv6 just do NAT and make my life easier like IPv4? What other options do you have so this isn’t so hard the next time around? Are there any tricks to make this less painful?
Let’s tackle these questions and see if we can get some reasonable answers to them. I would like to start with what you can do so it isn’t as hard the next time around. I would also suggest that this is a good place to start with your IPv6 project so you never have to go through this pain to begin with.
To do this, you need to understand the difference between Provider Assigned (PA) and Provider Independent (PI) IPv6 address space. To be clear, this concept existing in IPv4 also, it just isn’t as important in many cases due to NAT. What exactly is the difference?
Provider Assigned, or PA, (sometimes referred to as Provider Aggregateable) is IPv6 address space that is registered (with a Regional Internet Registry, or RIR) and effectively owned by a service provider. Such IPv6 address space is designed to remain with that service provider. It is address space that you borrow as part of your service agreement for your Internet circuit and the agreement states that you will return that address space to the provider once the relationship is terminated. Even so, there are no guarantees that the address space they provide you will remain with you for the lifetime of your agreement either. They may change the IPv6 addresses they provide you if your office moves, if they change your service delivery method, if you upgrade your circuit, or if they have some maintenance or other reason to change what IPv6 address ranges they can hand out to a customer in a given geography. The simple thing to understand about PA address space is that it isn’t truly yours, you are just borrowing some from your ISP. Eventually you will have to give it back.
Contrast this to Provider Independent or PI which is IPv6 address space that has been allocated to your organization from one of the five Internet Registries (ARIN, RIPE, APNIC, LACNIC and AFRINIC). Because this IPv6 address space is allocated directly to your organization it stays with you (so long as you pay your modest ARIN dues), regardless of which service provider you are utilizing at any given time. You can change your service provider, add additional service providers and even peer with other corporations and not have to change your IPv6 address space. This is obviously the more optimal configuration if you can do it. To use PI space you also need to have an Autonomous System Number or ASN. The ASN is what allows you to peer with your ISP utilizing BGP (Border Gateway Protocol) so that you can participate directly in Internet routing (sending and receiving prefixes to the global routing table). This routing method is what allows you to advertise your specific IPv6 prefix out to the public Internet through one or more Internet providers. Once you have PI space you will not have to renumber unless you want to for some technical or logical reason. Perhaps you renumber because the corporation is splitting into separate divisions and needs to operate separately or something like that.
If PI is not an option for your company (for whatever reason) and you are stuck with PA clearly you will have to deal with readdressing your network at some point in time. What can we do to make that transition a bit easier and less painful?
IPv6 does have some methods to allow for the renumbering of hosts. Regardless of whether you use DHCPv6 or SLAAC you can leverage some of the characteristics of Neighbor Discovery (ND) and specifically the Router Advertisement (RA) (such as Preferred and Valid address lifetimes) to help you push out information about new IPv6 prefixes that are available. Remember, hosts in an IPv6 network can have multiple IPv6 addresses and can have IPv6 addresses from multiple prefixes too, all at the same time. Because of this, you can control the lifetime of how long a host uses a given IPv6 address in a specific prefix.
The downside is that any manually configured or static IPv6 host addresses will have to be changed by hand or through some external method of configuration automation. In many cases networking equipment is set up with static IPv6 addresses. They are not resources that typically allow for any sort of dynamic address allocation and assignment at all. These network devices would be the first items to renumber. Once that renumbering is done, leverage DHCPv6 or SLAAC to assign a new prefix and hosts will begin to transition over. Once you have moved all associated hosts then you can simply remove the older prefix from the network device and you are done.
segment, you just wouldn’t have as large a window to perform the conversion. Often with IPv4 renumbering all the host endpoints are rebooted at the same time to convert everything in one maintenance window. You can certainly still do that with IPv6 also but given the flexibility of being able to readdress and not have a maintenance window at all, consider using some of the renumbering tools that IPv6 provides to make that happen.
So where does IPv6 Unique Local Addresses or ULA fit into this discussion.
You can find more discussion on ULA at:
Changing a host’s IPv6 address can sometime have adverse effects on things like remote management, services, and load balanced endpoints – just to name a few. For many operational teams, having consistent fixed IP addresses (IPv4 or IPv6) is a requirement to ensure that working access to host resources is available. If you are in the middle of an IPv6 prefix change, what host IPv6 addresses do you use? For some, this is where ULA has been considered useful. They are able to assign ULA IPv6 addresses to hosts and not change those addresses regardless of how many times they need to readdress their IPv6 network. Second, ULA is defined in RFC 6724 as less preferred than IPv4. This means from an operational basis, even though you have IPv6 deployed on your network with ULA, your hosts will still prefer to use IPv4 to communicate. This doesn’t really buy you much return for the effort of deploying ULA. Not until you deploy IPv6 Global Unicast Addresses (GUA) do you gain the enduring benefits of dual-stack or IPv6-only.
Clearly, there are some unique operational challenges with adopting IPv6 and the reality of potential readdressing is one of them. Unlike hiding all our hosts behind NAT devices and running our entire network with RFC 1918 IPv4 address space, IPv6 is designed to leverage the strength of having a globally unique address. The downside is the fact that it is publicly visible and therefore needs to be maintained as network infrastructure address changes happen.
As an aside, I have been asking attendees at many of the conferences I present IPv6 content at how often they change service providers. Typically I get around 1-5 percent that change frequently, every year or two. Almost all others (70 percent) do not change more than once every five to ten years. The remaining 25 percent have never changed and do not anticipate changing ever. I suspect the last category to be folks who already have IPv4 PI space and will do the same with IPv6. Given the majority fit in the five to ten year range an IP readdressing event would not be unexpected. You often are upgrading or changing out your network gear more frequently than that and you will likely have one or two major architecture refreshes within that timeframe. If that is the case, those will likely line up with a change of service provider and might present the opportunity to obtain and deploy your own PI IPv6 address space.
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
