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

[Suhas Nandakumar <[e-mail]>]

Hi Roman & Chairs

Thanks for the text

I feel we should restrict the scope for FQDN resolution to just one address
for this specification. Future specifications may define handling of
multiple resolutions (or  DNS64/NAT64 ) scenarios

If others are fine with this, I would want to get an updated draft and move
this forward


Please let  me know

Thanks
Suhas

On Wed, Apr 3, 2019 at 9:47 AM Roman Shpount <[e-mail]> wrote:

> Reposting er Flemming's advise as a new thread:
>
> Hi All,
>
> I have created a pull request to ice-sip-sdp (
> https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other
> things added back support for FQDN to ice-sip-sdp.
>
> In order to do this, I've done the following:
>
> 1. I have changed "IP address" to "connection address" throughout the
> document whenever address in c= line or ICE candidate attribute is
> mentioned. I hope this is not controversial since it matches ABNF.
>
> 2. I have changed the definition of <connection-address>
>
> Old:
>
> <connection-address>: :: is taken from RFC 4566 <<RFC4566>>.
> It is the IP address of the candidate. 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.
>
>
> New:
>
> <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
> 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 both AAAA record (assuming the agent supports IPv6),
> and using an A
> record (assuming the agent supports IPv4). If, and only if, the DNS query
> returns
> only one IP address it is then used for the remainder of ICE processing.
> If DNS query
> returned more then one result, including situation where single IPv4 and
> single IPv6
> results are returned, an agent MUST ignore the candidate. Handling of
> multiple DNS
> results for a 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.
>
>
>
> This change reflects what was discussed previously.. I am, personally,
> less then happy with this change. My biggest issue is requirement for FQDN
> to resolve to a single address or be ignored. In practice, this is
> problematic when things like DNS64/NAT64 are used. When DNS64 is used, even
> when FQDN was supposed to only resolve to IPv4, AAAA will also return
> result which will point to the NAT64 gateway. Based on the current
> language, this will result in candidate being ignored even though it should
> work with either IPv4 or IPv6 address. Most immediately, this will mean
> FQDN resolving to IPv4 will be ignored on a lot of mobile networks.
>
> I have also added language that defines what is supposed to be placed in
> c= line when default candidate is an FQDN candidate. What happens when FQDN
> resolution result and address family in c= line do not match was not
> specified.
>
> To summarize, this no worse then RFC 5245, but still fairly messy. I see
> two possible ways to clean this up:
>
> a. 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
>
> b. Specify that during ICE nomination all DNS resolution results for the
> candidate should be added as separate candidates to the candidate list.
> This is likely to cause more problems then option a. One of these problems
> that I see is priority values for these candidates. Candidate priorities
> should be different for all of them but only one value is specified in SDP
> candidate attribute.
>
> In order to simplify tracking changes, I will write different emails about
> other changes I've done in the pull request.
>
> I have also included people who shown previous interest in this topic.
> Please let me know if I need to cross post to rtcweb and ice WG.
>
> Thank you for your attention,
> _____________
> Roman Shpount
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>