3.1.5.21.1 Support for IPv6 transport addresses

According to [IETFDRAFT-ICENAT-19] section 5.1, an ICE a=candidate attribute contains two fields which transmit an IP address: connection-address and the optional rel-addr. Although the grammar permits these fields to contain an IPv6 address, a non-IPv6-aware user agent might malfunction parsing such an a=candidate attribute. This section describes an SDP extension for offering IPv6 ICE candidates as a way to avoid interoperability problems with non-IPv6-aware peer user agents.

A user agent SHOULD<36> be able to successfully parse a a=candidate attribute containing an IPv6 address in the connection-address and/or rel-addr fields.

If the receiving user agent does not support IPv6, it SHOULD ignore an a=candidate attribute containing an IPv6 connection-address. However, the non-IPv6-capable user agent MUST accept an a=candidate attribute containing an IPv4 connection-address field with an IPv6 rel-addr. The rel-addr field is not used in the ICE protocol itself, but is for informational purposes only, and so MUST be allowed by the receiving user agent.

If the user agent is sending an SDP offer or SDP answer and has ICE candidates with an IPv6 connection-address, then there is a concern whether the peer user agent will parse the SDP message properly. If the user agent does not know whether its peer is capable of parsing an IPv6 connection-address, it SHOULD use a new a=x-candidate-ipv6 attribute (defined in the next section) to transmit the ICE candidate.

On the other hand, if the user agent does know that its peer is IPv6-capable then it SHOULD use the standard a=candidate attribute to transmit an ICE candidate. A user agent can discover that its peer is IPv6-capable if a previous SDP offer or SDP answer received from the peer included an ICE candidate containing an IPv6 addresses (in either an a=candidate attribute or a=x-candidate-ipv6 attribute).