IPv6 Subnetting – Practical Uses

The concept of IPv6 subnetting may be intimidating to some, but it really is no different than in IPv4.  In fact, I believe it’s easier!  Sure we are moving from a 32 bit, dotted-decimal address to a 128 bit, coloned-hex address, but the idea is the same: break a network down into a number of smaller segments.  My goal here is to identify real-world use cases so you can see exactly how it applies to real life.

When learning about IPv4 subnetting, no doubt you were given questions like “Company ABC has a /16 network, with 1,000 office locations.  Anticipating 10% growth over the next 10 years, how many networks can be created, and how many hosts will fit in each of those networks?” or something along those lines.  Fortunately, in the IPv6 world, we don’t care about the number of hosts per subnet.  Why not?  Great question!  First we must understand a few differences with IPv6.  First, there are no broadcasts.  Communication destined for multiple nodes utilizes multicast.  Second, the standard IPv6 network is a /64, meaning 64 bits of the 128 bit address are used for the network portion, and 64 bits are used for the host portion.  64 bits allows for 2^64 or 18,446,744,073,709,551,616 hosts!  So basically, unless it’s a point-to-point link, we don’t care how many hosts are in it.  What we do care about, however, is the number of subnets we can create from an address block.

Everyone knows that 8 bits is called a byte, but did you know that 4 bits is called a nibble?  That’s not just useless trivia, but it’s a valuable thing to know when subnetting IPv6 because you will be breaking the addresses up on the nibble boundaries.  More on this later.

The smallest allocation assigned by most registrars is a /48.  A /48 is typically assigned to a “site.”  A site is defined as a single geographic location, which could be a single high-rise office building, or a small campus.  Let’s say you are assigned the following /48 prefix:  2001:db8:1::/48.  Remember, the 48 means the first 48 bits of the address is the network portion, and theoretically, the remaining 80 bits can be used for subnetting.  Practically, though, you don’t really want to allocate smaller than a /64, so that leaves you 16 bits for subnetting.  2^16 is 65,536 which means you can create that many /64 networks from your /48.

Now suppose you want to aggregate these 65,536 networks in smaller chunks.  Here’s where the nibble comes in.  The first nibble boundary in subnetting a /48 exists at /52.  How’d I know that?  Simple, 48 + 4 = 52.  Subnetting at this first nibble boundary allows you to break your /48 into 16  /52 networks.  They will be:

  • 2001:db8:1::/52
  • 2001:db8:1:1000::/52
  • 2001:db8:1:2000::/52
  • 2001:db8:1:f000::/52

That leaves you with 12 bits for subnetting.  2^12 is 4,096, which means your /52 can be broken down into 4,096 /64 networks.  As you can see, it can be very easily determined what network 2001:db8:1:2205:223:6cff:fe93:a3f4 is in.  In a campus environment with a dozen or so routing areas, a /48 can be broken down into 16 /52s, then assign each /52 to a distribution block/OSPF area, and then have a /64 assigned to each VLAN in that area.  You can even number your subnets with the VLAN ID!  If you have VLAN 205 in routing area 2, the 4th coloned-hex portion would be 2205.  This makes it really easy to glance at an address and be able to tell what part of the network it is on.

 Say you want to break your /48 down into more than 16 segments.  The next nibble boundary is at /56 (48 + 4 + 4 = 56).  This gives you 8 bits to use for subnetting.  2^8 is 256.  So your /48 is broken down into 256 /56 networks.
  • 2001:db8:1::/56
  • 2001:db8:1:0100::/56
  • 2001:db8:1:0200::/56
  • 2001:db8:1:ff00::/56
You have 8 bits left for the network portion, so your 256 /56s can each contain 256 /64 networks.  See where I’m going with this?  A /56 subnetting design may be practical for an organization with multiple dozens of locations.
Hopefully this information is useful in your IPv6 subnetting adventure!

So much time wasted for such a stupid problem

Let me preface this by saying that remotely rebooting a router/firewall always has associated risks; however, this one may never cross your mind as I’ve found out the hard way.  Apparently, Juniper does not want you to have a Cisco terminal server (aka reverse telnet) connected to their devices’ console ports.

I had been planning on upgrading from JUNOS 11.4R1.6 to the latest 12.1 release because I’ve noticed some weird/undocumented issues with its DHCP server implementation (to make a long story short, DHCP acknowledgments were taking excessively long to process and send out in response to a request).  After the old “request system software add … reboot” command I sat and patiently waited for the box to come back to life; unfortunately, it never did.

Almost by accident, I stumbled upon Juniper KB17145 entitled “SRX reboot can have problems when console cable is connected to Cisco terminal server.”  My favorite sentence is: “misconfiguration on the Cisco port can cause SRX not to boot properly”

This is how Juniper wants you to configure the Cisco serial port:

line aux 0
  session-timeout 7200
  exec-timeout 0 0
  no exec
  transport preferred none
  transport input all
  stopbits 1

So I applied their recommended configuration, rebooted the SRX, and magically, it booted properly!

The start of a new hobby

After much deliberation, I have decided to add yet another hobby to my list; model trains.  My plan is to build a small city in HO scale that has multiple layers.  For example, subway, street, and el.  Construction has begun in the spare bed room, however I am still acquiring materials, buildings, scenes, and of course trains.

Most people in the hobby strive for a realistic environment.  There are many techniques to “weather” buildings, cars, etc. to attain this goal.  I have practiced on a few trains, but have by no means mastered the technique.  Last week I had taken the train into the city and used the opportunity to collect ideas for my layout.

My first graffiti attempt:

It’s Been a While…

This blog originally began as a way for me to archive the progress of my aquariums.  As time has passed it has become more generic and includes other projects/hobbies in which I’m interested.  It’s been 6 months since I posted an aquarium related entry, so I figured an update was well overdue.

The 1290 gph Rio HyperFlow 20HF sure did the trick to get water moving from the basement up into the tank.  It actually pumps water up faster than it falls down.  After expanding the water volume of my marine aquarium by 100%, the ecosystem has clearly become more stable and things are growing like never before.  Below are a bunch of updated pictures.  Enjoy!

So You Want to be a Mac OS X Lion Server Admin?

Despite the numerous poor reviews of OS X Lion Server, I decided to take the plunge and shell out 50 of my hard earned dollars in order to utilize LDAP (Open Directory) services.  Now, it seems I have a slight case of buyer’s remorse…

I’ve used (and been quite happy with) previous versions of OS X server, but this is another one of those cases where the saying “you get what you pay for” comes to mind.  Previous versions of OS X server were $500 and $1,000 depending on the number of licenses needed.  Lion server does not appear to have a license limitation; however I have only added a hand full of items to the directory.  One of the first things I noticed was lack of options for configuring the small number of services offered.

All previous versions of Mac OS X server have come with “Server Tools” by default.  Lion server does not.  I downloaded version 10.7.3 of the server admin tools from Apple’s website, which gave me the applications to actually customize the services I am running, plus added a few other services (DNS, DHCP, RADIUS, etc.) that would not normally be available.

After seeing first hand how botched this version of OS X server is, I do regret buying it.  $50 could have been used towards a new CPU for my VMWare server.