gents. The service platform should not impose the IP connectivity to be used by a dual-stack SIP user agent. This requirement should be relaxed for some ser- vice considerations such as traffic matrix of IPv4 clients, the success rate of IPv4/IPv6 calls, to speed the migration to IPv6, etc. C 2009 by Taylor & Francis Group, LLC SIP and IPv6 5- Ability of a dual-stack user agent to place a call using its IPv6 connectivity with an IPv6-capable customer: This means that a dual-stack SIP user agent could select its IPv6 connectivity to place a call to IPv6 SIP user agents. The service platform should not impose the IP connectivity to be used by a given dual-stack SIP user agent. 3.3.2 Input from IPv6 Transport Migration The introduction of IPv6 into public networks is becoming a reality. Several service providers have enabled IPv6 in their routers and launched their IPv6 migration operations. The portion of IPv6-enabled routers differs between service providers. These migration operations should be tackled in the light of the following factors: - Backward compatibility: Network providers should ensure that running appli- cations still operate and are not disturbed when activating IPv6. Dedicated ALGs should be configured and installed in this aim, for instance, for applica- tions involving DNS and FTP. These ALGs will act as relays between the IPv4 and IPv6 realms and ensure a correct behavior of the end-to-end behavior of the involved applications. - Full coverage: Network providers should exploit the current global Internet connectivity, which is worldwide. Consequently, IPv6 realms should be seen as an extension of the already existing Internet and not a parallel one. IPv4 Internet should be seen from an IPv6 customer side as a continuity of its IPv6 connectivity. Reduce CAPEX: Introducing IPv6 in the network should not be synonym of network nodes each node is backuped. This task should be achieved without duplicating the network infrastructure. The spirit of the migration should be Evolve instead of Replace. - In