ral operating systems and their network drivers can make the 3GPP PDN Connection appear as an IEEE 802 interface to the IP stack. Sometimes even multiple PDN Connections are bundled under the same network interface, for example, when two PDN Connections of different PDN Types are used to mimic a dual-stack connection. One quite common approach is to connect the modem using a USB to a host, that is, between the TE and the MT. The USB based connection can be either external or internal, SO it is not only limited to 'USB dongles'. Deploying IPv6 in 3GPP Networks The USB-based network driver framework [36, 37] has a few known issues, especially when the IP stack is made to believe that the underlying link has link-layer addresses. First, the Neighbor Advertisement sent by a PGW as a response to a Neighbor Solicitation triggered by address resolution might not contain a Target Link-Layer Address option (see Section 4.4 of [157]). It is then possible that the address resolution never completes when the UE tries to resolve the link-layer address of the PGW, thus stalling all IPv6 traffic. Partial Neighbor Discovery Protocol Implementation on the Network Side Linked to the previous experiences of misbehaving end host driver implementations, the situation can be exacerbated. There have also been cases where the (old) GGSN simply discards all Neighbor Solicitation messages triggered by address resolution (this is because Section 2.4.1 of [157] is sometimes misinterpreted as saying that responding to address resolution and next-hop determination is not needed). As a result, the address resolution never completes when the UE tries to resolve the link-layer address of the GGSN, thus stalling all IPv6 traffic. Figure 4.31 shows a packet trace of this happening in a live network. There is little that can be done about this in the PGW, assuming that the Neighbor Discovery implementation already does the right thing. But the UE stacks must be able to handle address resolution in the manner that they have chosen to represent the S