ersion of [11]. The current version of [11] is independent of RFC 4191 and therefore removes the need for our own hook function and module. The existing kernel method for pushing Router Advertisement options into the user space could be reused with a few lines of code change. We recognize that our RFC 4191 extension for IPv4 more-specific routes would need a major push in standardization to reach wider acceptance. Future of IPv6 in 3GPP Networks Internet Protocol Version 6, Src: fe80: f24e (fe80:1214:4ff Internet Control Message Protocol v6 Type: 134 (Router advertisement) Code: o Checksum: 0x71f6 [correct] Cur hop limit: 64 D Flags: Ox00 Router lifetime: 1800 Reachable time: 12000 Retrans timer: 3000 ICMPV6 Option (Route Information) ICMPv6 Option (Unknown) x....X XOwib. Figure 6.2 A packet capture showing a Router Advertisement with RIO carrying a IPv4-mapped IPv6 address and the IPv4 default gateway address (which Wireshark interprets as unknown). 6.1.4 Concluding Remarks We discussed 3GPP-specified IP traffic offloading solutions and presented three IP-friendly offloading variations that are intentionally made to operate only at the IP level and make use of IETF protocols. A cellular operator can take advantage of the cellular network connection as a secure command channel to push offloading policies into the UE, while still only using standard IETF protocols. The implementation experience proved that IP level solutions using IETF-only technologies are feasible and lightweight to deploy both on the network side and specifically on the UE. One of the major challenges we faced was the support for IPv4 traffic offloading in operating systems. While modern IP stacks offer a rich feature set for IPv6 to imple- ment offloading in a multiple interface device, there is no clean solution available for IPv4. Another significant challenge is the resistance faced in the IETF community to using DHCPv6 or Router Advertisements for delivering offloading policies, and the per- sistent battle between DHCPv6 and IPv6 Neighbor 