d inter- connect with other service providers that can support only IPv6. In such a case, some adaptation functions should be implemented to allow successful communications between these two service providers' IP telephony domains. This latter case could seem to be fantastic and not operational but we believe that for global and universal reachability considerations this scenario is not far from reality (e.g., if China Telecom decides to enable IPv6 in its Next Gen- eration Core Network, the interconnection with this market-sensitive network is no more than the interconnection of an IPv4-only network and an IPv6-only one). In addition, the support of IPv6 in these extremities is a first step for preparing a full migration toward an IPv6-enabled SIP-based service platform (i.e., all service chain segments). The deployment of IPv6 in the access seg- ment is not justified nor motivated in case conversational service offerings are closely bound to the physical access of the customer and the IP connectivity services are based on IPv4. For service providers adopting this scenario (i.e., those having a clear strategy of progressive deployment of IPv6), the next transition step is conditioned by their service opportunities regarding IPv6 and the current limitations of IPv4-based deployment. After discussing some conditions under which this alternative is viable to investigate, some details about implementation scenarios of this alternative are presented below. Specifically, this scenario consists of maintaining IPv4-enabled SIP-based VoIP service core elements while only introducing functions to handle IPv6- capable customers when required. Therefore, the service is transparent for the end users as the service is offered by elements using the same connectivity as their SIP user agents. In other words, IPv6-enabled SIP user agents use IPv6 transport protocol to communicate with the service platform. This is notably due to the fact that IPv6-enabled SIP user agents must gain con- nectivity to the service (e.g., addressing 