n the existing 3GPP specifications. The UE uses the existing PDN Types IPv6 or IPv4v6 even when it wishes to initiate the evolved bearer. This comes from the design choice to build on top of the existing EPS Bearer. Obviously, if a network does not implement the evolved bearer neither does it initiate any traffic to the UE using other than the existing PDCP PDU types. If an eNodeB receives traffic from a mobile node that supports the evolved bearer, the unknown PDU types are simply discarded as per the existing specifications. Future of IPv6 in 3GPP Networks Since the evolved bearer router on the SGW breakout point does not survive a change of the SGW, there cannot be a case where the eNodeB would not support the evolved bearer but the SGW would have the evolved bearer activated. The MME is always the initiator of the activation of the SGW breakout/router on the evolved bearer. Note that the eNodeB can be in inactive mode on the evolved bearer while the SGW breakout/router is in active mode. Regarding the newly evolved specific PDCP PDU types, PDCP data (PDUs) carry Robust Header Compression (RoHC) [23] encapsulated IP packets. The same assumption also applies to the evolved bearer. 6.2.3 Overall Impact Analysis The evolved bearer has known implications for the 3GPP architecture and UEs, and additionally open issues. Here we will discuss about those briefly. Impact on the 3GPP Architecture Subscription profile currently contains service and even IP addressing provisioning information. There is probably a need to enhance the subscription profile and therefore also the S6a MME to Home Subscriber Server (HSS) interface [24] to carry an indication of whether a breakout/router is allowed in the eNodeB and/or the SGW. At the interface level the impact would be a single new enumerated Diameter Attribute Value Pair (AVP) stating the evolved subscription properties. The default behavior would be to not allow the evolved bearer. Policy and charging control (PCC) is not impacted at all in our evolved bearer design. We have 