Building

IPv6 Address Planning in 2016 / Observations

Hi,

I’ll be on the “IPv6 Panel” at Cisco Live next week and somewhat in preparation I started thinking about what we currently see when it comes to IPv6 deployment in our customer space. We notably observe a large gap between “textbook planning & transition strategies” and what’s happening in real-life in those organizations. I hence decided to write down some of these observations in a quick series of posts to be published in the upcoming days and, maybe more importantly, to reflect on the reasoning of this apparent mismatch between theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.

In many environments much energy has been (and still is) spent on the topic. Tom Coffeen wrote a book, Ivan Pepelnjak blogged about it and a while – actually it’s nearly two years, time flies! – ago I tried to contribute to the discussion as well (3, 2, 1; please note that these are here for mere referential reasons as I regard some of the things I wrote back then as outdated).

Creating an IPv6 address plan can be considered as one step within a bigger process. Let’s call that process “IP address management”. Management often includes a (presumably somewhat active) “steer & control” component as well as a (more passive) “administer what you have” side. With regard to IP address management I hence like to differentiate between a prescriptive and a descriptive approach.

The prescriptive approach can be summarized as follows: “come up with a plan, communicate & distribute it appropriately and IT/Ops will subsequently implement it”. The prerequisites for this to work out properly include:

  • Clear rules.
  • Coverage/range (“can you reach the people responsible for implementation, and their minds, and will they follow your guidance?”).
  • Governance (“if needed can you enforce they will follow your thoroughly thought-out and well-meaning guidance?”).

In contrast a descriptive approach can be summarized as follows: “accept that reality in large organizations is a complex beast, hence just provide a rough & somewhat liberal framework of guidance, but try to document existing reality as accurately as possible”. The prerequisites for this to work out properly include:

  • The right “supporting tools”, namely an IPAM system.
  • (High) maturity as for related processes, e.g. data collection.

Now, how well do you think the prescriptive approach is going to work in a world full of VUCA organizations, or in your own organization? Please raise your hands if you’d say there’s a sufficient IT governance for making all the gory details of your plan work in the upcoming years…

Long story short: I’ve been involved in many address planning exercises myself and I had the opportunity to follow to what degree plans I’ve contributed to 12–24 months ago (some of them created in numerous iterations over several months) are actually implemented in operational reality (you might guess the answer…).
As a consequence nowadays we usually recommend to have a rough plan how to assign prefixes to “large entities” like VRFs, sites or data centers, but to mostly omit any lower level categories like all the service/function related stuff. This mostly translates to: don’t fiddle with anything below the /48 boundary. If there’s one aspect though to pay additional attention to it might be network isolation on the routing layer.

In the next post I’ll discuss theory vs. reality in the “IPv6-only or Dual-Stack” space and/or provide some more observations from related areas. Please feel free to approach me in person in Berlin (or, ofc, join the panel) if you want to discuss any of these topics, or leave a comment here.
Best

Enno

 

Leave a Reply

Your email address will not be published.