Re: [MMUSIC] FQDN support in ice-sip-sdp

[Christer Holmberg <[e-mail]>]

HI,

I *think* I agree with Suhas that the FQDN handling should be a separate draft – a generic ICE draft produced by the ICE WG. ice-sip-sdp would then specify how it is implemented in SDP (separate a=candidiate lines etc).

Perhaps it could be combined with the mDNS draft?

Regards,

Christer


From: Suhas Nandakumar <[e-mail]>
Date: Thursday, 11 April 2019 at 11.03
To: Roman Shpount <[e-mail]>
Cc: Christer Holmberg <[e-mail]>, Suhas Nandakumar <[e-mail]>, "[e-mail]" <[e-mail]>, Flemming Andreasen <[e-mail]>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp


On Wed, Apr 10, 2019 at 12:36 PM Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
>Limiting FQDN scope to resolving to just one address is an unimplementable requirement. Currently on large number of devices, FQDN
>which is supposed to resolve to IPv4 address only, will resolve to both IPv6 and IPv4 addresses. For instance on virtually all IOS and most
>of the Android devices on mobile networks FQDN pointing to IPv4 returns results for IPv6 as well. Essentially what we are specifying now is
>that ICE candidates with FQDN address MUST be ignored.

Isn’t the main reason for allowing FQDN to enable usage of mDNS?

 It is now. Nothing in the latest language that I propose prohibits mDNS draft define how FQDN are supposed to work when mDNS is used. All my language states that default treatment for FQDN is to ignore it which keeps mDNS backwards compatible. I would also suggest adding an ICE option to specify that mDNS is supported. This being said, I am not sure mDNS prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is likely going to end up with two addresses for a single candidate.

In my opinion, the current ICE procedures assumes one IP address:port per candidate. If we allow a candidate to be associated with multiple IP addresses:ports, we would have to modify the ICE procedures in order to handle that: how a candidate can be part of multiple foundations (one for each resolved IP address:port), how the freezing/unfreezing procedure work, whether connectivity checks are sent to all resolved addresses, how the state of the candidate is set if one IP address:port succeeds but another doesn’t. Or, should the candidate be split into multiple candidates (one for each resolved IP address:port)? Etc etc etc etc etc. All of that could probably be done, but I think it would be quite a bit of work- an update (or even a bis) to RFC 8445. It is *NOT* an ice-sip-sdp specific issue in my opinion.

I am not suggesting changing that only one address is supported per candidate. What I am suggesting is that candidate needs some sort of hint when FQDN is used to specify how address should be resolved. Here is my proposed solution:

Add a candidate extension which specifies candidate address type, something like addrtype which can be set to "inipv4" or "inipv6". If IP address is used and it does not match the addrtype candidate extension, this candidate is ignored. When FQDN is used, it is resolved using A DNS request when addrtype is inipv4 or not present and using AAAA DNS request when addrtype is inipv6. Address family in c= line, when FQDN is a default candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6

Example:
a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local 60454 typ host inipv4
a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local 60454 typ host inipv6

I am not for or against the proposal. I am sure its fine.  I am concerned about the scope of this change and current implementations who are willing to support this new extension. Why can't this be in a total new draft ?



This keeps each candidate line to one address and works in cases when FQDN resolves to one IPv4 and one IPv6 address due to something like DNS64.

Regards,
 _____________
Roman Shpount