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

Hi,

Roman suggested text yesterday, and with my change suggestion it would look like:

<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 processing remote candidates MUST ignore candidate lines that include
candidates with FQDN or IP address versions that are not supported or recognized.  The procedures for handling FQDN candidates, and for agents
to indicate support of such procedures, need to be specified in an extension specification. If candidate with FQDN <connection-address> is the
default destination/candidate, 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.

The text in bold covers the must-ignore-FQDN-and-will-be-specified-in-an-extension-specification part.

Now, I have some difficulties to understand the last sentence. It seems to indicate that some FQDN DNS resolution is performed, and that the IP family is set according to the result. But, what if the result contains both IPv6 and IPv4?

Also, I assume that the procedures in the last sentence is related to the provider of the candidates. If so, it needs to be more clear.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Flemming Andreasen <fandreas@cisco.com>
Date: Tuesday, 21 May 2019 at 14.40
To: Suhas Nandakumar <suhasietf@gmail.com>, Roman Shpount <roman@telurix.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

On 5/21/19 1:01 AM, Suhas Nandakumar wrote:

On Mon, May 20, 2019 at 8:19 PM Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:
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.

[suhas] .. I don’t understand why FQDN resolution should be scoped in ice-sip-sdp whose main purposes is offer / answer negotiation and yes encoding provided candidates. I agree with Bernard and vote to move fqdn resolution outside ice-sip-sdp into a new draft

I'm leaning towards that as well. Trying to rush an FQDN solution into ice-sip-sdp does not seem like a good idea, and we need to move this draft forward.

Thanks

-- Flemming (as individual)

Also, using ice2 option does not help much since offer with FQDN in connection address would have to be generated before agent knows if remote party supports ice2. Bottom line is if remote party fails to parse FQDN there is nothing that can be done to generate an offer that will be compatible (except for putting FQDN in candidate extension). If FQDN is ignored or handled according to RFC 5245 procedure then it is safe to insert FQDN in contact address since either behavior would no worse then candidate pair connectivity check failing.

Roman Shpount

On Mon, May 20, 2019, 22:51 Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> 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 <roman@telurix.com<mailto:roman@telurix.com>> 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 <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> 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 <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 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

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic