plit-UE scenarios, is very difficult to do. And even if done, it would require tools for tunnel endpoint discovery, tunnel setups, and tunnel maintenance. This all further increases the signaling, which in general should be decreased rather than increased (existing networks are already suffering from large amounts of signaling traffic). 5.2.3 Mesh or Hub-and-spoke When selecting a suitable IPv6 transition and migration solution, either translation or encapsulation based, one architectural decision aspect is whether the solution supports mesh or hub-and-spoke [17] topologies. Some solutions may support both and the decision is then up to the network administrator. In hub-and-spoke topologies, several 'clients' (spokes) contact a smaller number of gate- ways (hubs) that typically perform the translation function or are just tunnel/traffic concen- trator points. Spokes do not communicate directly with each other. Within the translation/ migration context, the core network connecting spokes and hubs needs to support only one address family and the other families are then either translated or tunneled between spokes and hubs. A group of spokes typically gets locked to a specific hub. Dual-Stack Lite (DS-Lite) [8] is a textbook example of a hub-and-spoke solution. In mesh topologies, the 'clients' may communicate directly with each other, if allowed by the administration. The edge devices (routers) provide connectivity to core network external networks. Within the translation/migration context, the core network connecting clients and edge devices needs to support only one address family, and the other families are then either translated or tunneled over it. The transition/migration function itself may be done at the client or the edge device side depending on the technology. Since mesh IPv6 Transition Mechanisms for 3GPP Networks supports any-to-any connectivity, the transition/migration solution is implicitly stateless, at least on the edge device side. 6RD [5] using IPv4 anycast to reach the nearest Border Relay (BR)