{"id":4174,"date":"2019-11-15T16:36:32","date_gmt":"2019-11-15T16:36:32","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=4174"},"modified":"2022-10-19T16:23:16","modified_gmt":"2022-10-19T23:23:16","slug":"the-odd-history-of-provisioning-an-ipv6-address-on-a-host","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/the-odd-history-of-provisioning-an-ipv6-address-on-a-host\/","title":{"rendered":"The Odd History of Provisioning an IPv6 Address on a Host"},"content":{"rendered":"

IPv4 has two ways to provision a useable address on a host. You can either manually assign it (i.e., statically configure it on the host) or you can use DHCP. Technically, it is possible for a host to provision a self-assigned address in the Automatic Private IP Addressing (APIPA) range (169.254.0.0\/16) but this isn\u2019t particularly useful as self-assigned addresses cannot be used globally to connect to the Internet. This is true even through a Network Address Translation (NAT) gateway device, because the host configured with such an address has no way to determine the IPv4 default gateway.<\/p>\n

In IPv6, we have more options on how to provision an address on a host. You can use the following methods:<\/p>\n

    \n
  1. Manual assignment (i.e., statically configure it on the host)<\/li>\n
  2. Stateless Address Autoconfiguration (SLAAC<\/a>) (RFC 4862<\/a>)<\/li>\n
  3. Dynamic Host Configuration Protocol version 6 (DHCPv6<\/a>) (RFC 8415<\/a>)<\/li>\n<\/ol>\n

    One of the interesting aspects of IPv6 (as compared with IPv4) is the fact that it uses a router to announce information to the local hosts on a given network segment (a VLAN for example). The router does this through two main methods: Router Advertisements (RAs) and Router Solicitations (RS). Both methods rely on ICMPv6 messages delivered via multicast. We will focus on RAs, as they are a common method a router uses to share specific configuration information with hosts on a given network segment. The router shares this information by using two Router Advertisement flags<\/a> (M and O) to specify whether hosts should use DHCPv6 in the provisioning of an address (and if so, which method). There is also an A flag in the Router prefix information option header which is used to tell hosts if they should utilize SLAAC to auto-provision an address from the prefix that the router is providing. There are other additional flags, such as the On-Link (L) flag and the Mobile IPv6 Home Agent flag (H) but they are beyond this discussion. You can read about these in RFC 5175<\/a>.<\/p>\n

    In summary:<\/p>\n\n\n\n\n\n\n
    Flag Type<\/td>\nName<\/td>\nMessage<\/td>\nManual<\/td>\nSLAAC<\/td>\nDHCPv6<\/td>\n<\/tr>\n
    A<\/td>\nAutonomous<\/td>\nPrefix Information<\/td>\nNo<\/td>\nYes<\/td>\nMaybe<\/td>\n<\/tr>\n
    M<\/td>\nManaged<\/td>\nICMPv6 134 RA<\/td>\nNo<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
    O<\/td>\nOther<\/td>\nICMPv6 134 RA<\/td>\nNo<\/td>\nMaybe<\/td>\nYes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Some key critical elements must work on the host operating system to provision an IPv6 address. First, the OS must support IPv6. Secondly, the OS must understand what the RA is signaling–specifically, the A, M and O flag combinations. There are other flag options that can affect host OS behavior (L comes to mind) but we will set those aside to discuss another time. The breakdown above shows that there are a lot more combinations and options that IPv6 provides when compared to IPv4. In theory, greater flexibility means potentially more operational challenges since you have to account for many more variations, but we are only looking at one side of the process (from the network\u2019s perspective). We also need to look at how all the major OS manufacturers have included support for IPv6 in their stack.<\/p>\n

    Let\u2019s examine the major OS manufacturers and what they support.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    Manufacture<\/td>\nOS<\/td>\nSLAAC (A flag)<\/td>\nRFC 8106 – RDNSS (A flag + DNS info)<\/td>\nDHCPv6 Client (M & O flag)<\/td>\n<\/tr>\n
    Microsoft<\/td>\nWindows<\/td>\nYes<\/td>\nPost Windows 10 creators update<\/td>\nYes<\/td>\n<\/tr>\n
    Canonical<\/td>\nUbuntu Linux<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n
    Red Hat<\/td>\nRHEL<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n
    CentOS<\/td>\nCentOS Linux<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n
    Apple<\/td>\nMacOS<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n
    Apple<\/td>\niOS<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n
    Google<\/td>\nAndroid<\/td>\nYes<\/td>\nYes<\/td>\nNo<\/td>\n<\/tr>\n
    Google<\/td>\nChrome<\/td>\nYes<\/td>\nYes<\/td>\nNo<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    What you realize when you put on your operations hat is that there are only a few combinations of host OS address provisioning models that are optimal. Many of the operational choices are dictated by other factors. Those could be:<\/p>\n