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

[Bernard Aboba <[e-mail]>]

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