## 5 Experimental Setup, Analysis and Evaluations  
A complete multi-domain SoIDP6 network environment after following the migration was established as shown in Figure 4. We considered AS0 migration in this work, while the proposed approach is also applicable for other ASes. For example, during AS0 migration, gwr1, gwr2, and gwr3 are considered as CGs, and gwr4 is the FG. Similarly, for AS3 migration, routers attached to customer endpoints are CGs, and gateway router \"gr3\" can be considered as the FG. Due to resource limits, for this particular experiment, we supposed that AS1, AS2, AS3, and AS4 had hosts h1, h2, h3, and h4 respectively and tested the communications among those hosts over a SoDIP6 network environment. Figure 4 shows a complete dual-stack hybrid SoDIP6 network. Because every host and gateway is configured with dual-stack IPv4 and IPv6 addresses, it was implemented in the Mininet emulator running Ubuntu 14.04 virtual machine with ONOS/SDN-IP. The Quagga routing engine with Zebra daemon was enabled in the virtual machine, in which a separate instance of Zebra daemon was executed for each gateway to run the BGP daemon and follow the configuration details provided in ONOS/SDN-IP tutorial [23] regarding importing network, host, and BGP configuration details. The link to access the simulation program code and network/BGP configuration details is provided in the Supplementary Materials section of this article. The SDN-enabled dual-stack IPv6 network was implemented. The IPv6 address for a machine was generated using the mapping of the corresponding IPv4 address. For the six SDN switches in AS0, we ran a single instance of SDN-IP in the controller with a BGP speaker. All the gateway routers established iBGP peering sessions with the BGP speaker attached with the controller. The connectivity among the ASes, and hosts within the ASes, was successfully implemented. Similarly, reactive routing features enabled in the SDN-IP allowed for the communication among hosts from AS0 to hosts in the external ASes. The successful implementation of this SoDIP6 network with the legacy network integration shows that bigger enterprise networks like ISPs and Telcos networks can be smoothly transitioned into operable SoDIP6 networks. Taking the reference of this use-case, we performed extensive simulations for migration implementation, and controller placement with standard network topology following the set of constraints formulated in Section 4 with the Python NetworkX module as a network graph analysis. The proposed approach was implemented with Random, Abilene, Xeex and GEANT2009 networks downloaded from \"Internet Topology Zoo\" (www.topology-zoo.org), while the output of Random and Abilene networks are presented in Figure 5. For all networks, we ran simulations in two phases: (a) sequential replacement of routers from CG to FG with different RSS sets in the LSSP, (b) BFT to replace routers called BFR with different RSS sets in the LSSP. CG and FG routers were added after importing the network for simulations. For all networks, gwr4 was considered as the foreign gateway, while other gateways (gwr1-3) were considered as the AS gateways attached to the customer endpoints, recognized as CGs. Controller placement was defined based on the control path traffic latency by switches and the BGP-peers formed during migration. The green nodes in  
Figure 4: Implemented experimental environment of software-defined IPv6 (SoDIP6) network. CG, customer gateway, gwr, gateway router  
the figures are migrated, while red nodes are the gateway routers acting as iBGP peers with the ONOS-BGP speaker after migration. In Figure 5a, the routers in the LSSP are identified as (S1, S5, S6, S4). Similarly, in Figure 5b, the LSSP routers are [Chicago, Indianapolis, Kansas City, Denver, Seattle]. Hence, we simulated the network by setting those shortest path routers as RSSes and evaluated the switch and gateway latency to properly locate the controller.