06-28-2011 07:47 PM - edited 03-01-2019 04:41 PM
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.
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.
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.
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.
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:
(c/o US Department of Justice and Wikipedia)
The sites that we are rolling IPv6 to are in:
San Francisco (Site 9)
Seattle (Site 9)
Omaha (Site 8)
Newark (Site 3)
New York City (Site 2)
Boston (Site 1)
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!
Only one comment. The correct 'example/documentation prefix' is 2001:db8:: and not db80
This gives us one block of hex digits, or 32-bits, to use for subnetting.
This isn't quite correct; it is a block of hex digits, but that's "only" 16 bits. So you cannot have as many subnets as there are addresses in IPv4. But you can have as many (huge /64) subnets as you can have /24s if you have a "Class A" in IPv4, or a subnet for each IPv4 address in a "Class B". Still not bad!
That's what I was thinking as well... you have 80-bits to work with. Seems that using /64's leaves 16-bits to play around with.
@Alfred - thanks for the article! Seeing well thought out deployment examples helps, even if it may not necessarily match up with our business setup... Definitely food for thought.
I was thinking something that aligned well with VLAN ID's would be a good target - but obviously, route aggregation is a noble goal as well. Cheers.
@Raul - Whoops, put my 0 on the wrong side. I'll make it a point to update the doc with this change.
@Simon and Jason - Thanks for the feedback! I've made the change that it is 16 bits and not 32 bits.
Interesting article. Assumptions turned to reality:
I received a /56 from my ISP, and I currently have 200 locations that I would need to address. With current "rules" I only have 256 subnets available, correct?
Is it permissible to break the /64 boundary to allow for more growth. The company will be looking to expand further in the future, and 300 locations is not outiside the realm of possibility.
Thank you for your assistance and feedback.
You are correct that a /56 would give you 256 /64s.
(128 (total bits) - 64 (subnet bits on a /64) - 56 (your prefix length) = 8, 2^8 = 256)
Using something greater than a /64 should work, but be aware that you could negatively impact a number of built in IPv6 functions like PIM Embedded RP or Secure Neighbor Discovery. I'd suggest taking a look at RFC5375 section 3.
RFC3177 also suggests that /48s should be assigned by ISPs.
I would suggest asking your provider for a larger block of address space to better fit your subnetting requirements in the long run without needing to worry about breaking standards in the future.
Overall I would recommend against using prefixes greater than /64, except on point to point and loopback interfaces.
@jbesse74 - Perhaps consider requesting your own allocation? If you change providers re-addressing 200 locations doesn't sound like fun, even if IPv6 renumbering is supposed to be "easier." Note: ISP's are supposed to include a clause in their aggrement with you that they can take back the IP addresses at any time anyway, in case they themselves ever need to renumber.
Of course, your own allocation isn't free, and requires you meet some criteria. I'd check out https://www.arin.net/resources/request/ipv6_initial_assign.html to see if you qualify. With 200+ sites, your number of hosts may be enough to qualify. And, if you're considering becoming dual-homed on the internet, you'll need your own addresses.
I am a retail shop. Our sites are many, but not very big on network devices. The largest branch network I have, outside of corporate office, is nearly seventy devices, and that is just because it is a main distribution facility for our branch locations. The typical branch location only has at most twenty devices, and most even fewer than that.
At present we do not plan on being dual homed, but I do not know what my boss has in store for future planning.
Thank you for the information.
@jbessee74, my first thought when I read your question was "that's pretty shabby of your ISP to give you a /56 if you have 200 locations". And the more I think about this, the more I'm convinced that I'm right. And it precisely doesn't matter how small your locations are. Seriously, any decent ISP should give you a /48. And if your current ISP doesn't do that, well, then they should change that; and I'm sure that they can. If you ask them, maybe they'll want you to upgrade to a more expensive service. Within limits, I find this legitimate. But if they exaggerate, you should be able to find another ISP that has more reasonable IPv6 terms.
About using smaller than /64 for your subnets: I wouldn't go there, because it's bound to create many small (and possibly some not-so-small) operational issues, and there's really no reason to.
For many years, the IETF was pretty strict in recommending that /48s should be given to ALL end sites no matter what their size. Then the ISP community (which I consider myself part of) pressured them into allowing smaller ranges for tiny sites such as homes. So /56 got legitimized. Now, and possibly predictably, /56s are assigned to sites (like yours) that are CLEARLY NOT TINY. That's just wrong, and must be stopped.
@Simon Leinen: Thank you for the information. Everything that I researched so far, points to /64 being safe, anything beyond that, you have to be keep an eye on the two speacial bits 71 &72. I spoke with my boss yesterday, and I think he may look into getting our own allocation.
Thank you for the information.
Thanks alot, this is the best article I have found on IPv6 subnetting.
Thanks. Still learning
Excellent tutorial. Although I see the following errors. Correct me if I'm wrong
Management: 2001:db8:abcd:3eee::/64 --> if this subnet address belong to the Newark Subsite:
(2001:db8:abcd:3[f]00::/56) the second nibble in the set number four in the subnet address (3eee)
can not change, in this case the correct subnet address should be: 2001:db8:abcd:3fee::/64
Loopbacks: 2001:db8:abcd:3ffff::/64 --> a nibble more in the four set, sure fingers error, the correct address should be 2001:db8:abcd:3fff::/64
Juan Antonio Matos
Great catch Juan! 32,000 views and you're the first to see that.
I've updated the doc to correct these errors.
Good catch you can only omit leading not trailing 0
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: