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

[Roman Shpount <[e-mail]>]

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]> 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]> 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
>>
>>
>>
>>