from IPv4 to IPv4s (NAT44s) (both referred in this section as NAT), and firewalls other middle-boxes, which both place restrictions on how long transport layer sessions can stay idle, and whether incoming connections are allowed or not. Without any control on the network, the host implementations have to send frequent keep-alive signaling to keep NAT/firewall mappings open, and this can be a significant power consuming factor Future of IPv6 in 3GPP Networks in 3GPP UEs. Furthermore, without control for port forwarding rules of Network Address Translations (NATs) and firewalls, it is often impossible to receive unsolicited incoming connections. Automated solutions for the connectivity problems caused by NATs and firewalls in local area networks, such as home networks, have existed for a long time. The two most common solutions are Universal Plug and Play (UPnP) Internet Gateway Device (IGD) Device Control Protocol (version 1.0 [50], and 2.0 [51] that added IPv6 support) and NAT Port Mapping Protocol (NAT-PMP) [52]. Both of these protocols allow hosts to request a local NAT or firewall, a device usually in the host owner's control, to create port forwarding rules that will help applications on hosts. It is worth noting that manual configuration of port mapping rules to local NAT or firewall is often possible, even though it may be a cumbersome process and unscalable if mapping rules change often. While the UPnP and NAT-PMP have served local use cases, the emergence of carrier grade NAT44s and NAT64s has caused challenges. People are expecting to be able to use services like they could when they had public IP addresses that were not address translated, although introduction of NAT into the network makes that a troublesome goal. As technologies, the UPnP and NAT-PMP are not suitable for controlling a network entity in the operator's core networks. To bridge this gap, the IETF is actively developing a protocol called Port Control Protocol (PCP), which could provide end users some control of NAT or firewall in the oper