ators' core network [53]. At the time of writing, the PCP has not yet been published as an RFC. Therefore, it is recommended to check out the latest status of IETF's PCP working group. 6.4.1 Deployment Scenarios The most important deployment scenarios from the 3GPP networks point of view are illustrated in cases A and B of Figure 6.5. In scenario A, the UE implements the PCP client, and the NAT/firewall implements the PCP server in itself. This is the simplest of deployments. The difference of scenario B from A is that the PCP server is not located at the NAT/firewall, but instead on a separate network entity. From the UE point of view scenario B does not really differ from A. Obviously, from the network point of view, the difference is significant. The split deployment model is interestingly allowed by the PCP proposal, but the interface between the PCP server and the NAT/firewall is left undefined and to be implemented by proprietary solutions. Scenario C presents the deployment model that is the main use case for PCP. In this case, a CPE is implementing an interworking function between Local Area Network (LAN) and uplink Internet connection - which could be LTE as discussed in Section 6.3. Essentially, if the CPE would implement a NAT/firewall and had a public IP address on its uplink, the existing UPnP and NAT-PMP (NAT-PMP is not shown in the figure) protocols would be enough. However, if the CPE has a private IP address from the network provider, some means for extending the reach of UPnP and NAT-PMP are required. Hence, the CPE will implement a piece of software that converts UPnP and NAT-PMP messages the LAN to PCP messages on the CPE's uplink connection [54]. In all of these scenarios the NAT can be any kind of NAT, for example, the usual IPv4 to IPv4 kind, or also the NAT64 IPv6 to IPv4 protocol translator. Deploying IPv6 in 3GPP Networks PCP control NAT/Firewall control PCP control IP comms IP comms UE with NAT/Firewall UE with NAT/Firewall PCP client PCP client PCP server UPnP control PCP control IP co