Archive for September, 2012
Last year I came across an interesting IPv6 address plan, from the University of California San Diego (UCSD.EDU). Their networking group presented their IPv6 implementation status and address plan at the annual on-campus IT conference. Their address plan has some interesting features that I haven’t seen elsewhere.
UCSD is a large campus and currently has an IPv4 /16 (“class B”) and multiple IPv4 /24 assignments. UCSD also has an IPv6 /32 assignment. The campus spans about 2000 acres and serves about 30,000 students. The campus is large enough that having intra-campus geographically-based routing is useful, and there are about 30 main network nodes identified for this use.
UCSD’s address plan is:
- 2607:f720::/32 is UCSD’s assigned IPv6 prefix
- LR is actually vlrrrrrr in binary
- “v” bit is 0 (zero) for this version of the address plan
- “l” bit is “local”, meaning that any packet to or from this address is to be dropped at the campus net boundary
- “rrrrrr” is 6 bits that indicate the campus region, or major network node
- there are four zero bits at /40
- UUU identifies an organizational unit (department, lab, etc)
- SS provides 256 separate subnets per business unit
- <host> is a 64 bit Interface ID
This plan has a few unique features I haven’t seen in any other IPv6 address plan: a versioning scheme and the “local” bit. Note that there are also 4 bits (at /40) that are defined as “0” (zero).
The “version” bit does cut the present number of addresses in half, but that still leaves an astronomical number of addresses available, with the flexibility of having completely different address plans in the future, all coexisting.
The “local” bit is a kind of RFC-1918 (or at least peudo-NAT) replacement. Any address with the “l” bit set will be unreachable from the “outside” and unable to reach “outside” as all traffic to or from addresses with the “l” bit will be dropped at the campus network boundary.
They will also be delegating /56s or /60s to clusters, virtual machines, etc. Since UCSD (and SDSC.EDU) run a fair number of supercomputers and clusters of machines, being able to delegate large subnets is useful.
(My company is using OpenStack to build our own private cloud. OpenStack wants to dynamically DHCP large groups of machines as needed, so I can see why UCSD is reserving these large blocks.)
Defining an IPv6 address plan is an important process. Whatever you create will live on for years. Some analysis and thought up front can save time and pain later.
Before we dive into addressing plans, it is useful to look at the actual structure of an IPv6 address. While there’s lots of talk of “340,282,366,920,938,000,000,000,000,000,000,000,000 unique IP addresses”, that sort-of assumes that all addresses are usable (for any purpose).
Creating an address plan for all that would be a truly daunting task 🙂 Fortunately (for our purposes) a lot of the space is reserved and there’s some internal structure that we can take advantage of to simplify creating an address plan.
Over the years, many kinds and flavors of IPv6 addresses have been defined and some later removed (“deprecated”), such as “Site-local Unicast”. Also, restrictions or better definitions have been made for some address parts, such as the “Interface Identifier”, which will become important below.
Before we start, go read RFC4291. Go ahead, I’ll wait. Really, go read (or at least skim) it. You want to get a few things from this RFC… First, the standard hex notation for IPv6 addresses (Sec 2.2). Second, the prefix notation (Sec 2.3). And third, which will become important later, is Section 2.5.1, which specifically defines the size of the Interface ID as 64 bits.
Now let’s look at a regular old IPv6 address. From RFC4291:
The general format for IPv6 Global Unicast addresses is as follows: | n bits | m bits | 128-n-m bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+
Where does the global routing prefix come from? This is the address assignment for your network which comes from either your ISP for provider aggregatable address space (PA-space), or from a Regional Internet Registry (RIR) for a provider independent address space (PI-space) assignment.
If you’re a home user, IPv6 tunnel user, or a (small) end point business, you’re likely to have your address assigned from the pool that was assigned to the upstream ISP, provider (aggregatable) space. The drawback here is that if you change providers, your IPv6 addresses are going to change.
If you’re an ISP, not-small company or any organization that is multi-homed through multiple ISPs, you’re going to want provider independent space. Each RIR has different policies for address assignments, including the size of the assignment.
The important thing about that prefix is that you have no real control over it, either its size or its content. It is assigned to you and that’s it.
So, the Interface ID is always 64 bits, and the global routing prefix is fixed and assigned. That means that all you really need to worry about to create an IPv6 addressing plan is the subnet ID. Everything else is of a predetermined size, and in the case of the prefix, the content is also fixed.
The IPv6 address plan is really about how big your subnet ID is, and how it is broken down by purpose, location or any other information you may want to encode. Which is we’ll look at next time.
Space is big. You just won’t believe how vastly, hugely, mind- bogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.
— The Hitchhiker’s Guide to the Galaxy, Douglas Adams
The IPv6 address space offers some challenges to the network architect. It’s vastly different in scope and scale from our address-constrained IPv4 world. Network Address Translation (NAT), subnets-of-subnets, and other familiar workarounds just aren’t needed or helpful.
The biggest challenge in creating an IPv6 address plan may be overcoming decades of IPv4 planning experience. So much of “best practice” in IPv4 is exactly “worst practice” in IPv6.
Over the next several posts, I’ll be looking at how to create IPv6 address plans, registrar recommendations, IETF Best Current Practices, and practical considerations. I’ve found a few interesting address plans from some research organizations, too. While most of this won’t be needed by the home user, it may help understand what you’re seeing from your home IPv6 network.