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

[Roman Shpount <[e-mail]>]

On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg <
[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*

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