 can limit the need for such operations when routing optimization is considered. Solutions handling the two aforementioned chal- lenges are described in the section, "Handling Technical Issues Raised when Migrating SIP-Based Services to IPv6." 3.3.4.2 Second Alternative This alternative is an aggressive position toward the support of IPv6, but with precautions. This alternative suggests adding to the existing IPv4-enabled SIP-based service infrastructure new elements and to study the deployment and the support of IPv6 in all aforementioned segments (i.e., access, core, and border segments). These new elements may be IPv6-enabled or dual-stack ones. This alternative is suitable in case the density of IPv6-enabled customers becomes important and judged to evolve rapidly in the (near) future. Several scenarios to implement this alternative can be envisaged. An implementation example of this alternative is provided below. This alternative keeps untouched the existent IPv4 service platform in order not to perturb the service perceived by the already subscribed IPv4 customers (i.e., keep operational the physical equipment providing the conversational service). This option aims at exploring possible scenarios for enhancing the deployed IPv4 SIP-based VoIP platform by adding new service elements with- out impacting the existing service in order to offer similar service to IPv6- enabled customers. Specifically, it consists in the introduction of dual-stack elements where required in the operational architecture, in order to accom- pany the IPv6 deployment. This enables to isolate somehow IPv6 for the sake of IPv4 stability, while ensuring in the same time a smooth migration. Moreover, while this architecture will be field-proven, it should be possible © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security migrating pure-IPv4 elements to become dual-stack ones, through software upgrade hopefully, thus optimizing material investment. Unlike the previously described scenario, dual-stack elem