While IPv6 has been in existence for close to 20 years now it would be a mistake to say the protocol is not continuing to evolve to meet the needs of operators (service providers, enterprises and others). This is borne out in some newer RFCs that have been published recently. Earlier this year RFC 7078 (http://tools.ietf.org/html/rfc7078) which describes how to distribute IPv6 address selection policy preferences via DHCPv6 was published. Also, RFC 7157 (http://tools.ietf.org/html/rfc7157) which describes IPv6 multihoming without NAT was just published in March of 2014! Both are important steps in the evolution of IPv6 and both impact how service providers, enterprises and home networks will implement IPv6.
So, how do these new RFCs impact what you will do in your network design? First, in today’s IPv6 world a network team has to work much more closely with the operating system team to control host routing and address selection behavior. There are situations where you might have to make OS changes or enhancements to have a host behave the way an organization wants. Often this is outside the operational control of the network team and there may be many cases where it is even outside of the operational control of the systems team: For example, wireless or wired guest networks or hosts that are not centrally managed through Microsoft Active Directory or some other management framework.
The default source and destination address selection process is defined in RFC 6724 (http://tools.ietf.org/html/rfc6724) which was an update to the original RFC 3484 (http://tools.ietf.org/html/rfc3484). RFC 6724 allows for other methods to be used to control the address selection process and RFC 7078 was built to do exactly that. It allows networking teams that are managing IPv6 address space to specify what IPv6 address prefix a host utilizes to reach specific resources. This is important in environments that might have Unique Local Addresses and Global Unicast Addresses in some combination that does not behave in a manner consistent with what the network operator requires.
As IPv6 is used more, additional functionality will be required. RFC 7157 attempts to address how to better deal with multihoming without using NAT. This is a bigger challenge than originally anticipated for situations where an enterprise might have multiple IPv6 prefix allocations but not run BGP. One of the goals with IPv6 was to avoid all the mistakes made in the past by using NAT in too many locations. Often NAT is misapplied in designs and introduces unneeded complexity. Furthermore, NAT requires that applications be aware of how to traverse or work around NAT functions. This awareness will be much harder to put into the smaller devices that the Internet of Things will likely leverage. Small sensors with limited networking stacks using low power will have a difficult time dealing with NAT (compared to, say, a native IPv6 device providing the same function).
So, are you keeping track of what features and functions you require from your network, software and hardware manufacturers around IPv6? I would add RFC 7078 to my list. Remember, it will require both the DHCP servers and the operating systems and CPE devices to support it. Once that happens, we might just have a big improvement in the operational model for IPv6.
