An organization looking to get their arms around an IPv6 deployment has much to consider, when trying to build addressing plan. More details can be found here (http://goo.gl/o3KJ1w) and here (http://goo.gl/OP6KFB).
There are multiple choices; one that pops up right away is location based codding. This method typically uses the first 4 bits to encode a site, building, department or agency. The next 4-8 bits would further identify the address space as coming from a subset of the previous (perhaps a floor or building). The final 4 bits could either represent a direction (north, west) or function (i.e. voice, guest, etc.)
There is a drawback to this approach. In order for it work “cleanly” across the existing environment, the organization would need all legacy addressed subnets to be based on a /24 to avoid overlapping space.
This typically leads to the notion of encoding VLAN information in that space. This plan can work nicely because just about everyone uses less than 10,000 VLAN’s. Modern LAN switching equipment typically supports 4,096 VLAN’s. These quantities can be expressed in Hex to represent their decimal value within the 16 bits of “subnet” information.
The drawback to this solution is the potentially large waste of address space where gaps in the decimal linearity occur. Furthermore many organizations reuse VLAN ids across sites, which would lead to overlap or conflict within the address space.
Recommendations, so what should we do? Of course that depends on what makes sense to your organization, not just you the network architect. Consideration should be given to network operators, desktop support and your clients ability in attaching to networks. Experience with legacy protocols has trained us all to examine our default gateway, for troubleshooting purposes. We typically see the default gateway “neatly” configured from the same subnet we are attached to.
Our traditional behavior will have to undergo a change here. IPv6 requires a client to install the Link Local (IPv6 basics http://goo.gl/vlYxnJ) address of the device transmitting provisioning information (router advertisement) on that LAN interface. Meaning that our default gateway will be a link scoped address (fe80::/10), not from the same subnet (2001:db8:4646:1234::/64) as our global address.
One of the challenges we face when looking at these Link Local addresses is that they are “ugly”. This is because the default behavior for the routers is to use the EUI-64 format, which encodes the MAC layer address into the layer 3 IPv6 Link Local format. There is much talk about randomizing the host id and not using this method, even deprecating it. I believe that is still somewhat useful to map layer 2 at layer 3 for the local link, not the global addressing scheme.
What if we encoded the VLAN information of our router interfaces into their Link Local addresses? The help desk would know what VLAN was associated with every default gateway. The user/client will also have an easier experience in relating the default gateway that appears on their device. Below is an example of the default gateway for VLAN 234.
This method will provide useful information at the client link level, allowing desktop support, troubleshooting and client connectivity to perform more efficiently during your migration to IPv6. While it may be tempting to encode even more information in the bits of the Link Local, we should strive to keep it simple. We should also avoid encoding any information in 54 bits following the link-scoped reservation (fe80::/10). Said another way, we should use the host portion (last 64 bits) of the Link Local address for any information encoding.
Up next: Infrastructure on Link Local only, should we do it or not?