Monthly Archives: July 2012

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!