anslations, applications should be made IPv6 enabled. This, of course, is mainly the responsibility of application writers, but UEs can help by providing easy-to-use address agnostic APIs (see Section 3.9.2) and recommending and emphasizing the need to also use those APIs. When it comes to IP-aware applications, such as the generally "peer-to-peer" class of applications, those should be enhanced with the capability to understand IPv6 addressing. In this book we have provided some insights into what IPv6 means for applications in Sections 3.10.3 and 3.9.4. It is the combined responsibility for everyone to share information and requirements to get all applications into the IPv6-world. 4.8 Multicast IP multicast (and broadcast) delivery is realized using the MBMS service within the 3GPP architecture [49]. However, we are not going to describe MBMS in detail in this book as MBMS is not a wide spread service. Purely from the IPv6 point of view Section 4.2.2 has already discussed briefly which packet core network and RAN elements are affected by the MBMS service. In addition to radio network layer optimization, native IP multicast can be used within the 3GPP RAN and packet core as a traffic optimization mechanism to get the multicast traffic closer to the UEs that have subscribed to a multicast group or will receive the broadcast. In order to provide MBMS services, existing 3GPP architecture functional entities - GGSN, MME, SGSN, eNodeB, RNC, Base Station Controller (BSC) - perform several MBMS related functions and procedures, some of which are specific to MBMS. The MBMS architecture differs between GPRS and EPS. Figure 4.29 illustrates the MBMS architecture for GPRS. It should be noted that a GGSN is part of the multicast delivery. Within the RAN, an RNC or a BSC may also receive native IP multicast traffic. Figure 4.30 illustrates the MBMS architecture for EPS. In EPS the PGW is bypassed and the native IP multicast traffic is delivered as far as the eNodeBs. An MBMS specific functional entity, the Broadcast Multicas