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

[Christer Holmberg <[e-mail]>]

Hi,

> There was a bit of discussion earlier about this and the understanding was that RFC 8445 does not deal with FQDN or DNS resolution.
> RFC 8445 gets a list of candidates with IP Addresses. FQDN resolution as well as the format in which candidates are encoded would
> be a part of some other draft such ice-sip-sdp or an extension.

I agree.

As far as 8445 is concerned, each candidate is associated with an IP address and port. FQDN resolutions, encoding of the candidates etc are outside the scope.

Regards,

Christer


On Mon, May 20, 2019, 22:51 Bernard Aboba <[e-mail]<mailto:[e-mail]>> wrote:
I would recommend updating RFC 8445 to require that implementations that do not support FQDNs ignore them.  That way we can assume that implementations including an 'ice2' option will ignore FQDNs if they are unsupported.  Then the MDNS draft can cite RFC 8445.

On Mon, May 20, 2019 at 7:34 PM Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:
What do you suggest?

Most of the legacy implementations would fail to parse FQDN in the connection address.
Roman Shpount

On Mon, May 20, 2019, 21:55 Bernard Aboba <[e-mail]<mailto:[e-mail]>> wrote:
"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]<mailto:[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