and authentication), these functions being essentially provided by the access functional blocks. When considering current service provider architectures, a technical realiza- tion of this alternative is to let the core platform pure IPv4 and handle IPv6 at the access segment, especially in the SBC. The communication between SBCs and other elements in the service platform will be based on IPv4 and communication between the SBC and the IPv6-enabled SIP user agents will © 2009 by Taylor & Francis Group, LLC SIP and IPv6 be based on IPv6. Direct communications between SBCs can be either in IPv4 or IPv6, depending on the service provider policy. One concern is to provision SIP user agents with consistent configuration data leading them to connect to the appropriate SBC (all SBCs may not be dual-stack, notably in the early stages of IPv6 deployment). The provisioning of these SIP user agents can be achieved for instance via Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Service providers can indeed tune their DHCP servers SO as to provide appropriate information based on appropriate access control criteria. Within this scenario, SBCs must adapt and relay messages in order to filter IPv6 data. Therefore, for dual-stack SIP user agents, SBCs must retain and associate potentially two contact address types (IPv4 and IPv6) to a single IPv4 address used to represent the SIP user agent toward the core. SBCs must be enhanced in order to allow this correlation. SBC behavior must also evolve, especially regarding operations related to SIP registration. One challenge is that SBC should be able to identify customers' capabilities in terms of connectivity types. In other words, SBCs should have means at their disposal in order to discriminate the different SIP user agents. Another challenge is that these SBC elements should be configured SO as to optimize the media routing (minimize IP version changes). A simple call can indeed be decomposed at least in three legs, where at least two adaptation functions may intervene. SBCs