Skip to content

Latest commit

 

History

History
95 lines (82 loc) · 5 KB

Address and Prefix Management.md

File metadata and controls

95 lines (82 loc) · 5 KB
Raw

Address and Prefix Management

Three main cases can be distinguished:

  1. Unmanaged networks will generally use stateless address autoconfiguration (SLAAC, RFC 4862) within the subnet prefix(es) assigned to them by a service provider. This is in contrast to IPv4 practice, where DHCP is automatically configured in most unmanaged networks.

  2. Provider networks will generally configure prefixes and addresses on network elements, including customer gateways, according to a predefined plan as discussed in [5. Address Planning]. DHCPv6 Prefix Delegation OPTION_IA_PD may be used to assign prefixes to routers, even if DHCPv6 is not used for address assignment [2. Managed configuration].

  3. Managed enterprise networks will prepare an addressing and subnet plan that meets their specific requirements. To take a very simple example, an enterprise given a /48 prefix by its ISP might assign a /56 to each branch office and then assign /64 subnets as needed within each branch. The decision must then be taken whether to deploy SLAAC throughout the network, or to use DHCPv6 OPTION_IA_NA for address assignment [2. Managed configuration]. This choice has implications for both trouble-shooting and security incident management.

When a help-desk call or a security alert concerns a specific IPv6 address, the responder needs to know which computer and which user are involved. In some security cases, this may have financial implications and may need to meet a forensic evidentiary standard. Therefore, ascertaining the correspondence between the address, the device, and the user is a hard requirement for many enterprises. This is also known as address accountability.

In the case of SLAAC, the correspondence between IPv6 addresses and the MAC addresses of connected devices is embedded in the neighbor discovery caches of other devices on the same link, including the subnet router. This is volatile information, especially if IPv6 temporary addresses [RFC8981] or variable MAC addresses [draft-ietf-madinas-mac-address-randomization] are in use. This topic is discussed in section 2.6.1.4 of RFC 9099. A supplementary mechanism is needed to extract and log this information at a suitable frequency. An alternative would be to continuously monitor neighbor discovery traffic and extract and log the same information. It has also been observed that monitoring DAD (duplicate address detection) traffic will work, as described in this blog. All these solutions have unpleasant scaling properties for a large enterprise. A new approach is for hosts to actively register self-generated IPv6 addresses using DHCPv6 [RFC9686].

In the case of addresses assigned by DHCPv6, the IPv6-MAC address correspondence is embedded in the DHCP server configuration. In the simplest approach, MAC addresses are pre-registered and neither temporary IPv6 addresses nor variable MAC addresses are supported. However, this exposes the network to attack, since it is trivial to forge a MAC address with most modern equipment.

With either SLAAC or DHCPv6, the user of an unknown MAC addresses can be authenticated by IEEE 802.1X access control, and this would provide a robust link between the MAC address in use and the human user whose credentials were used for authentication.

An additional factor is that one widely used host operating system, Android, does not currently support host address assignment via DHCPv6. One solution to this, for a dual stack deployment, is to accept that affected devices will only use IPv4. Another is to have a separate WiFi BSS for "bring your own" devices (BYOD) where SLAAC is available, but this network will be treated as suspect and will be effectively outside the corporate firewall. A third solution is to offer no service at all for such devices, which will have to connect to a public cellular system instead.

A network operator must make a conscious choice between SLAAC and DHCPv6, in conjunction with their choice of IPAM (IP Address Management) solution if applicable. An important question is whether tools exist to meet the help desk and security needs described above for the specific vendor equipment and software in use.

This book does not recommend specific products. However, it is to be noted that an open source solution does exist that supports DHCPv6-based address management including dynamic DNS.

Next Top