other implementation dependent reasons, the UE IP stack may end up using an IID other than the one that the PGW told it to use. This opens the door for a theoretical DAD failure on the link-local addresses used on the link. Note that there will not be an address collision with GUAs since the PGW never configures an address for itself using the prefix advertised on the link. People might argue that an IP stack should handle the address collision as per normal procedures defined in [22]. On the other hand, we also know that some older PGWs may skip parts of the NDP, specifically the DAD procedure, because the address collision should not happen [157]. In practice the probability of an address collision is SO small that coming across one is not going to happen, except as a result of a programming error or when done on purpose. If the PGW neglects the DAD and a duplicate link-local address gets configured on the UE (i.e. the link-local address of the PGW is configured on the UE interface), then the following error case will happen. The UE comes to the conclusion that the colliding link-local address is unique on the link because the PGW never replies to DAD generated solicited-node multicast Neighbor Solicitations with undefined source address. Any further attempt to send traffic to the PGW fails because the packets are now destined to the local interface in the UE and no user plane IP packet leaves the UE. The destination cache may still hold the old entry for the PGW link-local address that was learned when receiving the Router Advertisement. Figure 4.32 shows an example capture where a UE is configured with a link-local address of the GGSN (i.e. fe80 : 1/10). As a side note, the (old brand) GGSN here does not answer the DAD originated Neighbor Solicitation messages. We start ping6 to 2001 6e8 2100 100 : 30 at the packet #41 and a entry gets created in the destination cache for 2001: 2100 pointing at fe801 (the link-local address of the GGSN). On packet #48 we manually configure the address of the GGSN on the UE in