Building

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 (=> 2nd 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 3rd 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

Comments

  1. I understand the advantage of using PI address space. But in the RIPE area a company that is requesting PI address space must fulfill the preconditions from ripe-552 and ripe-452. From my understanding: You need a contract with a sponsoring LIR with a contract matching the preconditions given in ripe-452. From ripe-552 I was expecting that the default assignment is /48 for PI space (except you can argue and proof the need for more). Working for a LIR my experience with PI customers (so far only IPv4) is that this results in extra stress and costs on both sides.

    1. Thomas,
      thanks for the comment. Actually it makes me realize I wasn’t clear on the approach and, even worse, used a terminology that was misleading.
      It’s not about $ENTERPRISE applying for PI space as an “end user” (as RIPE calls it; “end user organization” in ARIN lingo) it’s about “IT-Sys” ($ENTERPRISE’s group internal IT provider) acting as a LIR and hence getting an /32 _allocation_, as opposed to a /48 _assignment_. (this, of course, has some consequences as for handling that space which will be discussed in the second part).
      And I wanted to make clear that the requirements for becoming a LIR have been constantly lowered by the RIRs, to a level that I’d call them no longer existent for organizations of the $ENTERPRISE type.
      Best
      Enno

  2. I’m very interested in hearing more of your thoughts on this part:

    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. …

    In my sites, VLAN numbers follow subnet numbers, not the other way around. Therefore it makes perfect sense to me to retain this in my IPv6 plan. I struggle to understand why it would be a bad idea. I don’t consider it a sin at all.

Leave a Reply to Johannes Weber Cancel reply

Your email address will not be published. Required fields are marked *