Subject: [MMUSIC] ICEbis: Happy ICE balls

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jul 2016 09:22:48 +0200

https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-10#page-19

" <connection-address>:  is taken from RFC 4566 [RFC4566
].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When parsing
      this field, an agent can differentiate an IPv4 address and an IPv6
      address by presence of a colon in its value -- the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=candidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.”

After realising that STUNbis may lead to happy stunballs issues, I checked ICEbis, and
see one clearly here. If there’s a FQDN in the candidates, doing AAAA first
and then A is against all current advice on Happy Eyeballs-like situations. This has to
be configurable and propably there needs to be two probes, one for each address
and not in serial mode.

IPv4 only clients lookup A, IPv6 only agents lookup AAAA and dual stack clients
needs to look up A and AAAA - not just AAAA.

/O