 RR for statelessly configuring its uplink's IPv6 addresses. Case B of Figure 3.16 illustrates the use of the DHCPv6 PD Exclude Option. The DR has excluded the /64 prefix used on the link between DR and RR from the prefix delegated to the RR. Therefore, the RR has one /64 prefix less to use on the downlink LANs when compared to Case A, but on the other hand, the gateway has to maintain only a single route towards the RR. The saving of this one route can be significant in some deployments (e.g. in 3GPP, see Section 4.4.6). An important detail related to PD is that the RR assigns an Identity Association IDentifier (IAID) for each IA_PD option - this IAID is used consistently when the RR communicates with DR. The IAID is needed when the delegated prefix is being renewed, or if rebinding is needed due to, for example, RR reboot or RR's uplink connection Deploying IPv6 in 3GPP Networks disconnect/re-establishment cycle. Without IAID the delegated prefix could change too easily and too often, causing renumbering in LANs supported by the RR, and possibly causing unnecessary resource (address space) consumption in the DR. Stateless DHCPv6 In many IPv6 deployment scenarios stateful address autoconfiguration is not required, or wanted. However, often the hosts need configuration for various pieces of information, for which Router Advertisement (Section 3.4.3) is not a suitable tool. The solution for such cases is to use a stateless variant of DHCPv6, the 'Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6' [83]. The Stateless DHCPv6 is a subset of DHCPv6 RFC 3315. In essence, Stateless DHCPv6 defines that hosts must support DHCPv6 INFORMATION-REQUEST and corresponding reply messages. With the INFORMATION-REQUEST message hosts can ask for config- uration information - the same information that the hosts could ask for with full stateful DHCPv6 implementation, but without having to implement all of the DHCPv6 protocol. The lack of state in the stateless approach may cause issues if the configuration infor- 