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

[Christer Holmberg <[e-mail]>]

Hi,

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

So, if I understand you correctly, you are suggesting that the one providing the FQDN candidate splits it into two separate candidates (two a=candidate lines when SDP is used), and the remote peer will process them as two separate candidates, but if DNS returns both an IPv4 and IPv6 address the peer will only use the IP version indicated by the address type ("inipv4" or "inipv6").

Regards,

Christer