Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

[Bernard Aboba <[e-mail]>]

"If FQDN is allowed but ignored, this will allow "legacy" implementations
to interop with ICE implementation which support mDNS or generic FQDN. How
FQDN are resolved and how ICE agents specify to each other the these
procedures are supported can and should be part of mDNS or generic FQND
support draft. If I am missing something and something else is required,
mDNS authors should comment."

[BA] Unfortunately, RFC 5245 did not mandate that FQDNs be ignored by
implementations that did not choose to support them.  All it says is this:

<connection-address>:  is taken from RFC 4566
<https://tools.ietf.org/html/rfc4566> [RFC4566
<https://tools.ietf.org/html/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.


So while there are good reasons why modern ICE implementations should
support FQDNs (e.g. for NAT64 support), "legacy" implementations are by
definition not modern.  Given that RFC 5245-compliant implementations were
not obligated to either send FQDNs or to correctly handle them if they were
not supported, we need to look at what legacy implementations do, not what
we would prefer that they do.

Since RFC 5245 did not mandate either FQDN support or even resilient
behavior in non-supporting implementations, problems such as the one below
(or much worse) are to be expected:
https://bugs.chromium.org/p/webrtc/issues/detail?id=4165

So if were are attempting to interoperate with the vast body of existing
implementations, we should assume that we have to contend with legacy
implementations have been baked into equipment, or forked to create mobile
applications that have not been resync'd in years.  Note that this is a
very different circumstance from browser-browser interop where "evergreen"
is rapidly becoming the rule among WebRTC-capable browsers.

On Mon, May 20, 2019 at 4:14 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >If FQDN is allowed but ignored, this will allow "legacy" implementations
> to interop with ICE implementation which support mDNS or generic FQDN.
> >How FQDN are resolved and how ICE agents specify to each other the these
> procedures are supported can and should be part of mDNS or generic
> >FQND support draft. If I am missing something and something else is
> required, mDNS authors should comment.
>
> I don’t think you are missing anything.
>
> So far this is my proposal for ice-sip-sdp connection address definition
> which should implement option 2:
>
> ><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 FQDN or IP address
> versions that are not supported or recognized.  Handling of FQDN addresses
> in candidate can be defined in the future specification. If candidate >with
> FQDN <connection-address> is the default destination/candidate, the the
> "c=" address type MUST be set the IP address family for the FQDN DNS
> resolution result and the "c=" connection >address MUST be set to FQDN.
> Differences in the "c=" line address family and type with FQDN resolution
> result MUST not cause ICE support verification failure.
>
> Minor change suggestion:
>
> "The procedures for handling FQDN addresses, and for agents to indicate
> support of such procedures, need to be specified in an extension
> specification."
>
> Regards,
>
> Christer
>
>
>
>