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

[Roman Shpount <[e-mail]>]

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.

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