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

[Suhas Nandakumar <[e-mail]>]

On Mon, May 20, 2019 at 8:19 PM Roman Shpount <[e-mail]> 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



>
> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>