It's no secret that everyone just loves IP address management. Especially when it's done out of a spreadsheet or when some people think it's necessary and some think it's optional. The history of IPv4 is rather painful and it's not going to be used as a positive example anytime soon - unless we make an even bigger mess of IPv6.
As organizations (grudgingly) realize that you just can't ignore the 6 elephants in the room, they take their first steps and request an IPv6 address block.
What we, as engineers, do with these blocks will shape the way our networks will look like in the next years (and potentially decades). While I don't think there's such a thing as getting it 100% right (due to the ever-changing nature of technology), I believe that having a good think about it and drawing from the many years of crazy IPv4 growth we can plan a bit better this time.
So you got a /28 from your local friendly registrar and you're wondering what next? Well, I'll tell you: a lot of reading. OK, and some listening too. Before doing anything rash, start researching the problem (if you make it to the end you'll have a few links to follow through) and talk to other people who actually know something about this.
While this might be new for a lot of us, IPv6 is hardly new technology and some smart people have been thinking about these problems for years and years now. Most of us have blissfully ignored them, as the problems they addressed (pun totally not intended) were far away in the future.
I'd say this ignorance had two sides to it:
- side A: the belief that NAT and private addressing, together with crumbles of public space painfully extracted from the reluctant grip of registrars (or through other costlier avenues) would still last a long time, long enough that the mountain IPv6 is perceived to be (technologically, logistically, financially) didn't have to be climbed yet.
- side B: the realization that most of the IT services and applications would break when faced with having to replace IPv4 addresses with IPv6 ones. And it really hurts when you're a company that has no software development power and has to depend only on third party solutions.
This means that you don't only have to learn how to use this new and incredibly vast address space you just got, you also need to identify and target the problem areas in the supporting infrastructure and services. Your fancy routers might support IPv6 without breaking a sweat, but it's no use if you can't get at least some end-to-end services to function.
This was supposed to be a short introduction, so I'll stop here and get back to the matter at hand: some quick tips and tricks on how to start planning your addressing scheme.
NANOG BCOP
This is hands down the best collection of guidelines I could find - if there's only one article you can read, this is it. BCOP stands for Best Current Operational Practice, in case you were wondering.
You MUST read the whole thing, as they explain and give good examples. I won't fault you if you skim the main ideas before going more in-depth, so here they are:
- Every individual network segment requires at a minimum, one /64 prefix
- on multi-access segments (non-p2p)
- hard-requirement for SLAAC
- Only subnet on nibble (4bit) boundaries
- significantly improves readability
- reduces "fat finger" mistakes
- better operational efficiency
- might "waste" space by reserving too much where not needed (nibble gives 16 possible combinations)
- Implement a hierarchical addressing plan to allow for aggregation
- One /48 from each region should be reserved for infrastructure
- Loopbacks should be allocated from the first /64 as /128s
- Point-to-point links should be allocated a /64 and configured with a /126 or /127
- Sites/PoPs/Locations/Regions etc. should be laid out such that within each level of the hierarchy, each subnet prefix is of equal size
BRKRST-2667
For those wondering what that means, it's the code of a Cisco Live technical breakout session. You can get the video recording and slides for most of these for free from the Cisco Live website.
I saw it in a smaller setting at this year's Cisco Service Provider Tech Huddle and these are some things I wrote down (although you should really go ahead and watch it):
- Link-local
- embed info in the interface id
- Router ID, IPv4, VLAN, PINs
- ULA
- not for end-points
- needs NPTv6 (ugh!)
- example
- transit links use link-local
- routers use ULA loopbacks
- infrastructure is completely isolated
- but it creates problems with tools like traceroute
- Aggregation - /32 as bare minimum (big ISPs will have /19)
- P2P
- /127 RFC6164
- or allocate /64 and configure /127 (using :0 and :1 or :11 and :12)
- PI
- if splitting a prefix by country, check if it is accepted in other regions (e.g. RIPE prefix in APAC)
- embed info (but not sensitive data!)
- build in reserve
- assign a /60, reserve a /56 for future growth
- aggregate, aggregate, aggregate
- 4bit boundaries for readability (nibbles)
Anything else?
I had this post in the pipeline for a while now, especially as all the research was fresh from the necessity of actually slicing and dicing a brand new IPv6 prefix. The fact that in a couple of days I'm going to attend the first meeting of the UK IPv6 Council is a complete coincidence, I swear.
There's plenty more to check out, as simply searching online for IPv6 resources will show you. Ivan Pepelnjak has a multitude of posts on his blog, but also recordings of his fantastic IPv6 webinars.
I also enjoyed the RIPE document on how to prepare an IPv6 addressing plan - you know how most official white-papers have pictures on the front page of people being happy and positive and smiling? Not this one. A slight frown and a worried look is all you're allowed when talking about IPv6 addressing plans.
And, as always, thanks for reading.