Building Network Automation Solutions
6 week online course starting in September 2017

Enterprise IPv6 Deployments Are Not Hard

Luka Manojlovič, a networking engineer with strong focus on Windows and IPv6 sent me a short status update on an enterprise IPv6 deployment:

Moved a whole enterprise network (central location + 17 remote locations) to dual-stack today. So far everything works.

While that sounds pretty easy, there was a lot of work going on behind the scenes. Here are some of the highlights:

  • Configuring static IPv6 addresses and turning off DHCPv6 clients on Windows servers;
  • Adding IPv6 address pools to Windows DHCP servers and configuring DHCPv6 relays on remote routers;
  • Tweaking RA advertisements on all routers (and layer-3 switches for readers speaking marketese) to stop SLAAC and advertise presence of DHCPv6 information.

Obviously, his approach works as flawlessly as it does because he didn’t have to deal with the SLAAC-or-die religion embedded in Android.

Summary: deploying IPv6 in an enterprise network is not Mission Impossible.

On the other hand, do keep in mind that Luka focused on practical aspects of IPv6 for years, so don’t expect to replicate his feat without significant investment in training, testing and piloting.

As always, you can either build the expertise or buy it (hire an expert), and while buying might be more expensive, it will definitely be faster and less error-prone. Not that I would expect some IT managers to heed this advice.

Want to start building your IPv6 expertise? Start at


  1. - You forgot: Disabling all kind of IPv6 tunneling adapter or you could have some fun with your DNS

  2. As much as I'm interested in HOW it was done, I'm more interested in WHAT the business case was. I bring up the topic at least once per year, and occasionally a director will swing by to ask, "Are we doing IPv6?". Other than MDA, the answer is no. We have a /36 with ARIN, we have a schema developed for the enterprise, we have arrangements in place with our carriers to advertise our /36, and we even validated that our load balancers could host v6 versions of our public sites in case we only want to do it at the edge. But we still have done little to nothing. Why? The VP or CIO will ask, "What will it cost me to do this, what will it cost me to not do this, what are the opportunity costs and what is the technical debt?" That pretty much douses any interest in pursuing IPv6. I'd love to know what drivers were provided to Luka, or how he sold it to leadership.

  3. I don't see why a business should NOT have a case for deploying dual-stack in their environments today.

    If I recall correctly, ARIN was, or still is, handing out IPv6 assignments for free or for extremely low cost compared to IPv4. Aside from the easy administrative work involved, if your operation wants to scale and/or is a global service, IPv6 should have already been on your radar as some countries don't have as large of IPv4 space as we in the United States do.

    When speaking about the "costs" of doing this, of course, anything you make a special case will cost more money. Instead, roll out IPv6 slowly, as part of your hardware/software refreshes, or maintenance cycles, or whatever it is you find yourself doing on a regular or semi-regular basis. I do agree, from a software perspective, the configuration comes with a ton of technical debt because not all vendors have full IPv6 support, or even IPv6 support against the latest standards.

    Nonetheless, going dual-stack is easy, I've done it many times with no issues, but it does demand you read the documentation and double check with your hardware and software vendors for any other known/internal bugs or caveats. We need to stop treating IPv6 like some new magical creature, it is just another IP addressing scheme, understand it, accept it, deploy it, and one day we'll all be talking about IPv4 in the same context as Token Ring or IPX/SPX.

  4. Although, I did forget to mention that native IPv6 deployments, at least using todays most common/popular software and hardware for the data center, is a fool's errand.

  5. The deplyment in itself is usually not so hard. What is very hard, sometimes almost impossible is having the binding decision that says "We WILL (MUST) do IPv6". Without such a decision v6 deployment is usually just a one-man show.

  6. No mention to how securing this double stack was made either. Connecting w/o security does not seem very wise. Securing times 2 is 2 times the exposure surface. Oh well.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.