IPv6 Address Plan Considerations, Part 1: General Guidelines

In an upcoming series of blog posts I will discuss some principles & considerations on developing an IPv6 address plan. In (hopefully) rather quick succession there will be three posts:

• the first  on some general rules as for IPv6 address planning which we regard instrumental in the process.
• the second covering the “PI space from a single RIR or PI space from each (relevant, as for $ORG) RIR?” debate.
• the third on actual approaches to structuring/grouping each region’s /32 (or /36) into subdivisions like sites, VRFs, facilities, use types, buildings, whatever. I understand that this part is probably the one quite some readers are most interested in; still for a reasonable line of thought the others have to be covered in advance.

As you might have already spotted from the prefix lengths mentioned above, the presumed setting (read: the main audience) of this piece is a sufficiently large enterprise organization with sites/subsidiaries/plants all over the globe, potentially mainly in the EMEA, APAC and Americas regions. So if you’re [with] a service provider organization, a university or small[er] organization, some of the recommendations I lay out might not apply to you. This focus (or restriction thereof) is for the simple reason of ignorance. Given I haven’t been involved in many address planning efforts in such organizations I don’t feel qualified to advance opinions on their settings.

Let’s think of a fictional enterprise organization (group) with a global network which is mainly operated by a group(-owned) IT service organization (“Company IT Systems”, shortened to “IT-Sys” in the following). Let’s further assume that IT-Sys has been operating as a Local Internet Registry (LIR) for IPv4 in the past and they’ve already been allocated an IPv6 /32 (PI space) from RIPE. As noted above I’ll discuss in the next post if it makes sense for them to apply for PI space at other RIRs and how to tackle this.

Another point: after this very section, I won’t mention ULAs in the whole document/series. As many other people smarter than me I have a strong dislike for ULAs and don’t think there are many reasonable use cases (in global enterprise networks) for them. You should avoid them wherever you can. Why? Simple answer: to get out of address selection hell.

Last but not least: I’m fully aware that some of my writings might be controversial, but, hey, that’s what a blog is for ;-). Feel free to get back to me by dm or by leaving a comment any time. You might also discuss (not only) these topics with some experts like Ivan Pepelnjak (who, of course, has written on some of them before) and us at the Troopers IPv6 Security Summit.

Now, let’s start with some general rules to keep in mind when designing an IPv6 address plan. You’ve probably heard most of them before, nevertheless this could be a helpful reminder here+there:

Dont‘ Expect to Get it Right at the First Try

Usually you (and your colleagues & consultants) will need several rounds of reflection & iterations to identify the address plan that could be fitting. I know that some of you don’t believe me here (saying to themselves: “once we’ll think about it hard enough we’ll be able to sit and write it down in one single effort”) but trust me: I’ve yet to see an environment where the first try turned out to be the one to stay with.

Go For PI Space. Period.

Think about it: any renumbering effort would probably already heavily hurt in your current network. Now multiply the perceived pain with some orders of magnitude and might you get an idea what it would mean to renumber your then IPv6 network in some years…

There’s a simple exit from such nightmares: go for & with PI space. It’s never been so easy for “end user organizations” to get PI space as of early 2014 and once “IT-Sys” acts reasonably smart, it will receive a LIR allocation (which is not an “assignment” then) which means at least a /32. Been there done that, several times.

This can be undertaken at different RIRs (=> 2^nd post which will also cover how to handle the then-LIR space routing-announcement wise) in different regions. Please keep in mind you then must be willing to pay the associated fees (as of late 2013 in the US$ 2000 range for a /32 at RIPE/ARIN/APNIC) and you’ll need a corporation/legal entity in the respective RIR’s space. Plus: those guys (that legal entity) will receive the RIR’s invoice. Make sure there’s somebody on-site who has an understanding what this [invoice] is [for] and who takes care of getting it paid ;-). Seriously!

I’m fully aware of the implications of this recommendation on the Internet routing level. It implies a severe tragedy of the commons and I’ve read RFC 4984 more than once. Still, if you’re an end user organization the best thing you can do is to proceed this way. I sincerely apologize to all those carrier people reading this right now and, rightfully, being concerned as for their TCAM size of their routers. I understand and accept you having “negative feelings” into my direction here…

Forget about Being Conservative and Plan for Growth

Rest assured: there’s enough IPv6 addresses for this world, the Internet of Things, our kids and their kids. Again, I know some of you won’t believe me (muttering that “640 k ought to be enough for anybody” quote – falsely – attributed to Bill Gates) but it is my firm  belief that you will be able to get along with a /32 (or a couple of them) for a very very long time.

So for the sake of consistency and scalability be generous when planning. If you have 77 units at some subdivision level of your scheme (e.g. 77 sites within a region) go with eight bits (=> 256 potential “units”) at this level. Same if it was, say, 44 sites ;-).

You’ll hear about different ratios (“reserve half of your space”) and approaches (“start in the middle so you can expand to the edges”) here. I don’t really have a strong preference on those. Do whatever you like, but take a broad view.

Don’t even Think about Touching (Exceeding) the /64 Boundary

Nothing more to say here. Well, ok, configuration-wise you might go with /128 on loopbacks and, maybe – yet another topic to be discussed at another occasion 😉 – /127  on p2p links (RFC 6164…), but design-wise your smallest units must be at least /64s. Period.

Forget – Once and For All – that Ugly Three Letter Word

0x4E, 0x41, 0x54

Stay on Nibble Boundaries

For readability reasons try to stay on nibble boundaries wherever possible, so defining subdivisions with (bit) lengths which are multiples of four (4). If you run into problems with this approach (e.g. not being able to create “enough” units at any structuring/subdivision level) go back to start, re-think and, if needed, apply for larger address space.

Consistency is Key

Assuming your “starting point” is a /32 most probably you’ll have enough addresses/space for any reasonable approach so, as I said, forget any “IP address conversation” thinking you got used to in IPv4 times.

Whichever of those grouping/structuring approaches to be covered in the 3^rd part you choose (sorry, again I humbly ask for your patience ;-), you should strive for utmost consistency as for prefix lengths assigned to individual regions, VRFs, sites, use types etc. (IPv6 network) things will soon get complex anyway so there’ll probably a point in time you’ll be happy of any simple, consistent structure you got used to.

An example might be helpful: let’s assume you’re starting point is a single /32 “for the [‘your’] global network”. Following the “reserve some spare” you might first put one /33 aside. Now, let’s assume that your main production / presence is in Europe (and forgetting the nibble boundary thing for a moment) you might contemplate about sth like “one /34 for Europe, one /35 for APAC, the other /35 for the Americas”. Don’t do that! Try to go with the same prefix length for each level of the structure, say a /36 for each “region” (if that’s an addressing subdivision type you’re going to work with which is what I’ve seen in most organizations with a single [RIR’s] /32).

In this early stage of IPv6 deployment in your organization, avoid exceptions at any cost. Given the dynamics of most organizations & their networks you‘ll have to cope with them anyway sooner or later.

Coverage is Key

Try to include all possible types of networks you can think of in your organization (“office IT”, industrial control networks, building automation, fire alarms etc.) and put those under one & only, consistent scheme.

Don’t Retain your Sins from the Past

You’ll sometimes hear about or be tempted to map(ping) $SOME_HISTORICAL_STRUCTURAL_ELEMENT like VLAN IDs or “IPv4 3rd octets” of your IPv4 network into IPv6 addresses. Don’t do that, for a number of reasons:

• If you’re amongst the 95% of organizations where, over time, VLAN numbering and/or IPv4 addressing has become somewhat messy you’ll just transfer this chaos… and you don’t want to start your long journey into a bright IPv6 future with such bad debts, do you?
• Furthermore such approaches don’t scale, they will eventually clutter readability & consistency and hence come into your way in the mid-term.
• Once you want to implement efficient IPv6 ACLs on routers (oh, this could be a topic for a blog post in the future… ;-)) such a scheme might turn out not to be particularly helpful either.

 

That’s it for today, stay tuned for the next part coming in a few days. Thanks for your precious time & have a good one everybody

Enno