URI scheme name. sip6 Status. permanent URI scheme syntax. sip6:[:]@[:][;][?] The scheme is the same as for sip: with the exception of the URI scheme. URI scheme semantics. SIP entities [RFC3261] that process the sip6 scheme URI ensure that the following additional constraints for the sip6 URI scheme are not broken, by implementing them inasfar as it concerns their processing: * All SIP, media descriptive and media traffic that follows from a sip6 URI scheme MUST be communicated over IPv6, and describe IPv6-capable resources. * All RTP traffic that follows from a a sip6 URI MUST support ZRTP [RFC6189] and actively attempt to establish ZRTP. Descriptions of such RTP communications SHOULD offer ZRTP. These additional requirements describe a method of deploying SIP that brings it nearer to its ideal configuration; namely, without any need for an intermediate party in the media path. There are advantages to deploying configurations that only work within these constraints, but with only a sip URI scheme such configurations would not be discovered until a call setup was being attempted, leading to potential end-user experiences of broken calls. The sip6 URI scheme is intended to avoid that problematic behavior. Applications/protocols that use this URI scheme name. The Session Initiation Protocol can be used with the sip6 URI scheme. With the exception that the aforementioned additional requirements apply, the processing is not in any way different. Specifically, the protocol continues to be named SIP in transport descriptions, and _sip._udp continues to be used a DNS name for SRV records. The syntactic declaration of support of this scheme can help to make an early selection of the proper tools, either by an end-user who can be properly informed, or by generic browsing tools that start different handling agents for the sip and sip6 URI schemes. A SIP phone that dials a sip6 URI can be certain that IPv6-only communication suffices; the phone can refuse attempts to dial such a number if IPv6 is not available, and prefer a sip URI alternative if it is available. On the other hand, current SIP phones that only support IPv4 will not recognise the sip6: URI scheme, and as a result skip attempts to contact them. There is no prohibition on translating proxies that map the sip6 URI sphere to the sip URI sphere, provided that the sip6 side of such proxies conceals the parts of the sip side that are not compliant to the additional requirements on the sip6 side. Interoperability considerations. The sip URI suggests a capability to communicate over IPv4 and IPv6, but in practice these protocols are incompatible. The result of having both address schemes under the same URI scheme can lead to interoperability problems. The introduction of a separate URI scheme for SIP over IPv6 improves this situation, by reflecting the incompability of the IPv4 and IPv6 spaces in an easily processed form. The required support for ZRTP implies that any implementations that use RTP but do not implement ZRTP facilities are inoperable with the sip6 URI format. This too is a deliberate choice that leads to more certainty to be derived from the connections being setup. Security considerations. The usual security considerations for SIP apply, with the exception that the requirement of ZRTP support reduces the risks of phone tapping and man-in-the-middle attacks. Contact. Rick van Rein Author/Change controller. Rick van Rein References. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC6189] Zimmermann, P., Zfone Project, Johnston, E., Ayaya and Calls, J., "ZRTP: Media Path Key Agreement for Unicast Secure RTP", April 2011.