ular connections could be sending a Router Advertisement with more specific routes. That could result in a conflict of interest and offloading policies. Still, if the router preferences are set correctly on the cellular side and alternative accesses are available, the offloading to the alternative accesses would take place. And furthermore, each PGW could still deterministically mark the destinations that must go through them using more-specific routes. Enhanced Neighbor Discovery with IPv4 Support To overcome the limitations of the IPv6-only RFC 4191 approach, we have proposed new IPv4 traffic specific Router Advertisement options [11]. The new options enable access routers to convey an IPv4 default gateway address and more-specific IPv4 routes. In a prototype made for IPv4 offloading, the existing Linux kernel implementation of linux/net/ipv6/ ndisc.c had to be extended by adding an intercepting hook function (kernel offload hook) and one module (kernel offload module) to push more-specific IPv4 route and the IPv4 default gateway address Router Advertisement options from kernel to user space via the sysfs interface. In the user space, an IPv4 offload daemon handled the main tasks for IPv4 traffic offloading by manipulating IPv4 routing tables. Figure 6.2 shows a cap- tured Router Advertisement message, where the RIO option carries an IPv4-mapped IPv6 address : ffff 77.0/120) to route an IPv4 subnet to the Router Advertise- ment originating router. The Router Advertisement also carries the default IPv4 gateway address of the dual-stacked router as the last option (10. 6 i.e. 0a 06 06 06). All this was needed because currently Linux's IP stack sends only few selected Router Advertisement options into the user space - RFC 4191 options are processed within the kernel, and IPv4-mapped IPv6 addresses in RIOs do not affect IPv4 routing, and we had no other way of changing the IPv4 default gateway on demand. Note that the proof-of- concept implementation, whose capture is shown in Figure 6.2, was based on the earlier v