IPv6 – an interesting address plan (UCSD)

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:LR0U:UUSS:<host>
  • 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.)

Having so much address space available offers all kinds of opportunities to encode information into the addresses themselves. Only time will tell if this is a good use of the large address space or not.
Advertisements
  1. IPv6 – creating an IPv6 address plan – the hypothetical company « Thuktun (Message)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: