The sheer number of bits in an IPv6 address can make IPv6 subnetting intimidating at best. With the addition of a new addressing scheme it's easy to get lost trying to break up your brand new /48 address across your enterprise.
The New Boss, Same as the Old Boss
Subnetting with IPv6 is not drastically different than subnetting with IPv4, we just need to keep a few things in mind:
1.) Each character in an IPv6 address represents 4 bits (a nibble).
Since 0xF is 1111 in binary, it's easy to fall back into an IPv4 habit and forget that 0x11 is actually 0001 0001 in binary.
2.) Each IPv6 set represent 16 bits (4 characters at 4 bits each).
Keeping this in mind can make breaking up subnets a bit easier.
3.) Once it's in binary nothing changes!
It's easy to get lost in so many binary digits but the math is all the same. Each subnet bit is one fewer host bit and vice versa.
Setting the Ground Rules
The leading practice is to receive at least a /48 prefix from an ISP. This leaves you with 2^80 bits to manipulate (128 bit address - 48 bits that can't be changed = 80 bits to use). More bits than the entire IPv4 address space!
According to RFC4291 the current recommended smallest prefix is a /64. With so many addresses in IPv6 there isn't the same need for address conservation as there is in IPv4. You can assign a /64 to a point-to-point link and not feel guilty. The only exception to this is the recommendation from ARIN to use a /128 on loopback addresses.
This gives us one block of hex digits, or 16-bits, to use for subnetting. One block might not sound like much, but 16-bits is half of the entire IPv4 address space.
Defining the Site ID
In order to allow for proper route aggregation and summarization you should define Site IDs that you can use at each location (be that an office, data center or geographic region).
This is where we need to define at least a Site ID, and possibly a sub-Site ID.
If we are assigned 2001:db8:1234:0000:/48 from our provider, as mentioned, we have the "0000" to manipulate for site, sub-site and subnet IDs.
How you should break this down depends greatly on your business needs, but the easiest way may be to break things down along the nibble boundary. This can give us a few options:
4 Sites, 4 sub-sites (at each site), 4096 subnets (at each sub-site): first 2 bits for the site, next two bits for the sub-site (first nibble), next three nibbles for subnets (2^12).
16 sites, 16 sub-sites (at each site), 256 subnets (at each sub-site):
First nibble for the site, second for the sub-site and the last two for the subnet.
16 sites, 256 sub-sites (at each site), 16 subnets (at each sub-site):
The first nibble for the site, the second and third for the sub-site and the final nibbles for the subnet.
IPv6 Subnetting Case Study
We have a mid-sized company with offices and data centers across the United States. As part of our long term planning we have applied for an IPv6 address and were assigned 2001:db8:abcd::/48. We now need to allocate this across our enterprise.
We have branches in most states, so we've decided to use Option B, giving us 16 sites, 16 sub-sites and 256 subnets per site.
We've decided that a "site" will be a geographic region of the country and a sub-site will be a city within the geographic region. Here is the breakdown we are using for our sites:
At this point we can assign site and sub-site prefixes.
Each region will match the number on the map:
Site 0 - 2001:db8:abcd:0000::/52 (for future use)
Site 1 - 2001:db8:abcd:1000::/52
Site 2 - 2001:db8:abcd:2000::/52
Site 3 - 2001:db8:abcd:3000::/52
Site 8 - 2001:db8:abcd:8000::/52
Site 9 - 2001:db8:abcd:9000::/52
Site 10 - 2001:db8:abcd:a000::/52 (for future use)
Site 11 - 2001:db8:abcd:b000::/52 (for future use)
Site 12 - 2001:db8:abcd:c000::/52 (for future use)
These are /52s, because we have 48 bits from the provider and then the next 4 for the site.
Next we can assign our sub-sites:
Future Use - 2001:db8:abcd:1000::/56
Boston - 2001:db8:abcd:1100::/56
Future Use - 2001:db8:abcd:1200::/56
Future Use - 2001:db8:abcd:1a00::/56
Future Use - 2001:db8:abcd:1b00::/56
New York City - 2001:db8:abcd:2000::/56
Future Use - 2001:db8:abcd:3000::/56
Newark - 2001:db8:abcd:3f00::/56
Omaha - 2001:db8:abcd:8000::/56
San Francisco - 2001:db8:abcd:9100::/56
Seattle - 2001:db8:abcd:9200::/56
Just like the site, the sub-site uses 4 more bits, moving our prefix length from a /52 to a /56.
Within each site we can now assign our subnets. We will use our Newark site as an example.
Firewall Outside: 2001:db8:abcd:3f00::/64
Database Servers: 2001:db8:abcd:3f02::/64
Mail Servers: 2001:db8:abcd:3f0d::/64
We are defining the next two nibbles for the subnet so our mask moves from a /56 sub-site up to a /64 subnet prefix. Newark's subnets can use 2001:db8:abcd:3f00 through 2001:db8:abcd:3fff:: for subnet addresses.
Within each subnet we can provide 2^64 addresses, as we still have 64 bits to use.
For example, within the MailServers vlan we will start all addresses with 2001:db8:abcd:3f0d:: and the last 64-bits are for the host.
We've assigned the following addresses
mail gateway: 2001:db8:abcd:3f0d::1/64
With IPv6 not relying on IPv4 anymore we finally address the poor addressing schemes we've all had in place for years. By defining sites and sub-sites, with plenty of room for growth we can do some pretty heavy duty aggregation.
Each of our sub-sites will advertise their /56 prefix up to an aggregation router.
Each aggregation router will be connected to the IPv6 Internet and announce both our enterprise wide /48 and the site /52. This provides redundant connectivity via the internet and allows the internet to use longest match to reach the site directly.
Of course you'll want to do what works best for your organization and aligns with your business goals and requirements. There are no requirements regarding the site and sub-site or even how these are broken down. These are provided to help you get a better grasp on how do assign IPv6 addresses. Don't forget, when you get stuck you can always call TAC!
Hi, I am still learning all of this stuff but this should be pretty straight forward. I am trying to configure a gateway of last resort for this lab I'm doing for school, I've created a static route every other way and they've all worked. For some reason ...
I have some 100b with older code 15/16.x and vMAnage will not recognize them. How do I manually update the code to 19.x or are there a series of commands to force it to recognize vMange? thanks in advance, Ben
Hi all, I have a Cisco C921-4PLTEGB currently connected to the EE network using its Cellular interface.I have one VLAN (VLAN10) setup to connect back to our corporate network via a tunnel. All traffic by default should go down this tunnel for DH...