We’re regularly asked to review IPv6 address plans from different organizations and I’d like to share some reflections from such a process currently happening. I’ve discussed a few aspects of IPv6 address planning before; those readers interested please see this post which contains some references.
The organization in question is headquartered in Germany, has ~60K employees and a number of subsidiaries in European countries. They belong to a “traditional industry sector” (so they’re not an “Internet company”, even though they – as the majority of large organizations right now – strive to be one in a few years ;-).
The proposed IPv6 address plan is somewhat oriented along the “flexible” scheme I laid out in the #TR18 NGI “IPv6 Address Management – The First Five Years” talk (I was involved in the plan’s creation in an early stage but haven’t been recently). The most interesting part for our discussion is that they plan to use the 45th bit as a kind-of flag to differentiate between “external” (bit = 0) and “internal” (bit =1) networks.
Before we have a closer look at this particular aspect please allow for a quick recap of basic thoughts re: IPv6 address planning. First we should keep in mind that there are different stakeholders in an IPv6 address management process (of which the creation of a plan is only one, early step) incl.
- the planners themselves. Usually they exhibit a huge dose of the very human desire “to be in control” (no irony or malice here); I mean why else would you be participating in an activity which Merriam-Webster defines as follows: “planning […]: an orderly arrangement of parts of an overall design or objective”?
- operations personnel – the poor sods who have to live with the outcome of the former gang’s work. They can be from the own organization or from one or several outsourcing partners (the latter being the case in our example).
- various other groups like security people, architecture board members etc.
Secondly one should always remember that address planning is not an end in itself, but is supposed to support the achievement of specific objectives which must be identified beforehand (and weighted/ prioritized by those involved, not least as there might be conflicts between individuals goals). This is the slide from the above talk showing the objectives we like to focus on, plus a weighting approach which we consider reasonable:
I will discuss those objectives in our individual case in a second.
When questioned *why* they propose said bit differentiating between “internal” and “external” networks the answers were along the lines of
- somebody looking at an address might be able to quickly identify if this [address] is from an “internal” vs. an “external” network. (if one had a nitpicking nature, which ofc doesn’t apply to me, one could go on asking: “but *why* would that type of identification be helpful?” (apart from creating one of those little life moments of feeling smart 😉
- “we could use this in firewall rules”.
- “we might use this for routing purposes of all types”.
Some of you, dear readers, might have now an initial gut feeling of scepticism based on thoughts like
- the inherent dichotomy (there’s an “external” world/part of the network vs. an “internal” one) doesn’t reflect reality in the vast majority of corporate networks of sufficiently large organizations.
- overall this looks a tad too static for real-life use.
- how would one handle (the multitude of) scenarios where, at a later point, a network initially dubbed as “internal” needs to be handled in a way similar to “external networks” (ability to receive inbound connections etc.)?
and these are all legitimate (+ I share those) but still I suggest to tackle the (review) task in a structured way, by just asking – for each of the above objectives – the simple question to what degree this bit might be beneficial for $OBJECTIVE.
Here we go.
Persistence (avoid renumbering in the future)
Once a subnet’s specific attribute (here: the “topology aspect” of being on one distinct side of some type of boundary) is coded into an (IPv6) address there’s two options once this attribute changes (which is a not-so-unlikely scenario given the dynamics of modern networks):
- renumbering (how often have you seen this happen irl? and there’s good reasons for the answer…)
- create an exception (“usually we drop all traffic destined to ‘internal’ networks on the firewall, but for this subnet there’s this little extra rule”, or “we just put in this nifty longer-match routing entry” etc.) which in turn might thwart the exact objectives initially pursued by the approach, and evidently this will foil the ever present quest of smooth operations.
Applicability (facilitate machine-based processing/decision taking)
On the first glance that (“external vs. internal”) bit seems to nicely support this one. Point just is that I’d expect that in the mid-term the effort to keep “the idea aligned with reality” (see above) would create the contrary effect (*more* filtering rules of a more complex nature, more entries in routing tables, more regex for parsing etc.).
Scalability (does it allow for growth?)
Here it should be kept in mind that scalability is not just about growth & numbers, but also – and even maybe more importantly – about flexibility and (support of various) use cases. Don’t want to be the killjoy here, but again I’d have serious doubts. How would one handle cloud networks or “mobile IoT devices” or other “future” types of networks & their populating entities with a scheme using the bit/flag in question?
Support for Routing Based Security
As stated above the approach initially looks good with regard to this one. However we don’t estimate that there are many corporate networks being able to pursue a strategy other than “null-routing of selected prefixes” (for a few “crown-jewel” type of networks), if at all (any proper strategy). See this post for a more detailed discussion.
Ability to Aggregate
Yeah, route summarization would be doable (provided one manages to keep the approach over time, yada yada yada). May I ask: who needs route summarization anyway, in a mid-sized enterprise network equipped with today’s networking gear?
Ability to Delegate
I don’t see how such an approach (the 45th bit) could support this in a reasonable way…
Legibility
Let me state first that this is usually the most over-rated ones of the objectives (we’re all humans and as such susceptible to subtle fallacies along the lines “isn’t my brilliant scheme immediately understandable to everyone?”… incl. those persons in an outsourced NOC of the sourcing party responsible for operations in 10 years, after the second or third cost-driven datacenter migration…). Nuff said.
===
Conclusions: I can’t really recognize the operational benefit from such an approach/such a bit. Namely in the mid- or long-term I could imagine that this causes way more harm than good.
As stated a few days ago we’re always happy about having a good chat on IPv6 topics and/or getting feedback on various channels. The upcoming #TR19 NGI IPv6 track could be a nice opportunity for such a conversation.
Cheers, Enno