IPv6 addressing scheme for existing IPv4 network

A lot of enterprises and hosting providers are getting into IPv6 finally and ideally are running dual-stack so they can offer their users/clients native IPv4 and IPv6.  If you’re retroactively adding IPv6 to an existing network, especially a network consisting of web hosting servers, that can be kind of a pain since you need unique IP’s for all of your users and/or websites.

A technique I like to use for adding IPv6 to an IPv4 network without conflicts, AND which makes it easy to know what VLAN you’re on, AND with static assignment, AND that would be very unlikely to ever generate the same address as SLAAC (but even if it did IPv6 Duplicate Address Detection would deal with it to prevent interruptions in service), is this:

  1. Obtain your first /32 from your regional registry; we’ll use the IPv6 documentation prefix of 2001:db8::/32 in this case.  This is a prefix used for documentation and articles, not internet-routable.  Note the db in that example address are represented in lowercase; that is intentional per RFC 5952 from the IETF.
  2. If you’re connected to the internet, you’re going to want to be announcing the entire /32, so don’t worry about chopping it up if you figured you would be announcing smaller portions from different ASN’s if you have data centers scattered about that don’t talk to each other behind the scenes.  The longest IPv6 prefix you should be announcing via BGP to the internet is /32 and that’s all that’s safe to announce because much of the network operations community doesn’t want to see IPv6 routing tables get polluted with tons of needlessly specific announcements like IPv4 has.

    Some registries do issue /48’s to end users (not service providers) but there has already been evidence of some large ISP’s ignoring prefixes longer than /32 so if you are issued a /48, I’d recommend asking for a /32 instead or you may find yourself unreachable from some ISP’s.
  3. With that being said, I like to use the third 16-bit field for a site identification, which means we’re going to be internally breaking up the /32 into LOTS of /48’s for logical sites but internally we’ll really just be using /64’s from a routing perspective.

    For example, let’s say you have a data center in Los Angeles and one in Las Vegas.  We’ll go ahead and call them sites 1 and 2, but you can of course use any four digit hex value of your choosing if you prefer to do something funny like beef, food, dead, etc.  So anyway, that gives us two site-specific /48’s:

    2001:db8:1::/48 (Log Angeles)
    2001:db8:2::/48 (Las Vegas)

    Now, at the site level, I like to use the fourth 16-bit field for VLAN ID’s because it just makes things easier to keep track of, debug (with traceroute showing what you know to be a vlan id), etc.  Additionally, SLAAC requires the network to be a /64 to work so generally you want all of your networks that contain actual computers/end-points to be /64’s anyway.  So let’s say you have five VLAN’s in Las Vegas, 500 through 505.  Well now you have a /64 ready to allocate to each VLAN:


    It’s unlikely that you’ll have more than ~65,000 VLAN’s per site, since that would be impossible (12-bit VLAN id’s in the IP packets remember?) so this typically will provide you with more than enough address space to encompass any site-specific network configuration.  You can also use a /64 like this for router to router interfaces with smaller networks if you choose to, or just a /64 for each routed link.

    So where does this become useful?  Well let’s say you’re debugging something and can’t figure out why traffic is not working correctly.  Your IPv6 address is 2001:db8:2:502::5/64 and you’re trying to trace to something on 2001:db8:2:503::5.  You can’t ping your default gateway of 2001:db8:2:502::1.  You check your switch, oh, it says your port is on vlan 504.  Well you immediately know your IPv6 address is wrong for that network because you put in 502 for the fourth 16-bit field.  Switch it and the gateway to 504, now it works.  Or, let’s say ping to a specific name is failing; “ping6 server101.mydomain.com” says 2001:db8:2:504::10 not responding.  Hey, without even bothering to look at some network diagram or IP database, you already know the destination server is on vlan 504, so now you can jump right to the router for that network and see what’s up.

    If you don’t like this idea, you can use this fourth 16-bit field for anything else of your choosing.
  4. So now that you have your network addressing scheme, you can then use the final four fields for host addresses.  That will give you 18446744073709551616 per VLAN; I think that should be enough lol.
  5. So the next thing I like to do is, when adding IPv6 to an existing IPv4 network, come up with an easy way to assign IPv6 addresses to all the devices that currently have a static IPv4 assignment.  IPv4 devices using DHCP can simply use SLAAC so you don’t have to do anything special.

    Since we can represent the entire IPv4 internet with just two of the four available fields, I typically just turn each of the IPv4 address octets into the corresponding hexadecimal number and use it for each of the four fields.  For example, let’s say on VLAN 500 in our Las Vegas data center (i.e. the 2008:DB8:2:500::/64 network) we have a computer with IP address  Converting each of those four octets to hex, we end up with 192 = c0, 0 = 0, 2 = 2, 100 = 64.  So our resulting IPv6 address to give that device is 2001:db8:2:500:c0::2:64/64.  Notice the double colons; you can do that once per IPv6 address more than one consecutive 16-bit field has a value of zero; this is NOT optional, you must do this, with the largest consecutive grouping, or the left-most grouping if there are more than one equal-length groupings of zero.  If there are multiple non-adjacent sections with zero values, you can’t do that twice; i.e. 2001:db8:0:0:1:0:0:1 would be 2001:db8::1:0:0:1.  RFC5952 mandates that you compress the first occurrence of consecutive zero fields, so do NOT use 2001:db8:0:0:1::1.  More info on this at my other article HERE.

Would love to hear any feedback/comments on whether you agree or disagree with this method.  I don’t typically work on other people’s IPv6 networks, I come in to help deploy it from scratch so I don’t get to see much of what others have done in the IPv6 world.

Leave a Reply

Your email address will not be published. Required fields are marked *