Re: [MMUSIC] Question about draft-ietf-rtcweb-mdns-ice-candidates

A few thoughts from looking at the solution you are proposing.

In general, the fact that the candidate priority is affected might not prevent the connection to happen.
I am not sure a change of the candidate priority warrants adding the expected address type.

If an ICE agent gets multiple IP addresses from resolving a FQDN candidate, the ICE agent might either drop the candidate or select an IP address from an unexpected address type.
This might affect connection establishment.
As Qingsi said, the draft contains mitigations so that this situation should not happen for mDNS candidates.
This could potentially happen for non mDNS FQDN candidates but is outside the scope of the mDNS draft.

> On 15 Dec 2020, at 06:25, Roman Shpount <roman@telurix.com> wrote:
> 
> Based on this, do you assume that the ICE agent will directly resolve MDNS candidates without using any third-party libraries or going through DNS proxies?
> 
> My concern is that DNS proxy running in the CLAT in the mobile device can translate IPv4 address to IPv6 address. I was looking for an implementation where CLAT is located on the device is running in combination with MDNS but could not find anything. I think DNS translation is done in the client library on Android when 464XLAT is used, but I might be wrong since I don't directly deal with this.
> _____________
> Roman Shpount
> 
> 
> On Mon, Dec 14, 2020 at 3:40 PM Qingsi Wang <qingsi@google.com <mailto:qingsi@google.com>> wrote:
> > Is it possible for an IPv4 MDNS name allocated by one end-point to be resolved as IPv6 address by another end-point, or visa-versa (IPv6 MDNS name be resolved as IPv4)?
> 
> I don't think so given the requirement in the draft and also available implementation options of mDNS responder in an ICE agent. The draft requires an ICE agent to expose different mDNS names for each address if it uses an interface with both IPv4 and IPv6 addresses. As a result, even if there is caching in the subnet by other endpoints and another endpoint tries to reply to a query for the name, the resolution should be consistent. As an implementation strategy, the ICE agent can 1) set the cache-flush bit in their response (and/or announcement) per RFC 6762 to indicate this is not a shared record type and purge inconsistency in the subnet, and 2) attach a NSEC record in the additional section of the response to indicate the sole existence of either A or quar-A record of a name. This is admittedly all based on the assumption that there is no rogue endpoint that tries to mess the local messages, which is a different story outside the scope of this draft.
> 
> > I specifically would like to know if something like 464XLAT can cause MDNS resolution results to be converted to a different IP address type.
> 
> I don't recall behaviors like this in 464XLAT or NAT (not expecting them to change the packet payload).
> 
> On Mon, Dec 14, 2020 at 12:06 PM Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> wrote:
> I have a general question about MDNS that will affect the mdns-ice-candidate draft:
> 
> Is it possible for an IPv4 MDNS name allocated by one end-point to be resolved as IPv6 address by another end-point, or visa-versa (IPv6 MDNS name be resolved as IPv4)?
> 
> I specifically would like to know if something like 464XLAT can cause MDNS resolution results to be converted to a different IP address type.
> 
> If this can happen, then the MDNS candidate can generate more than one local candidate or a candidate of a different address type, affecting candidate priority. I think the stability of the FQDN candidate resolution, including the MDNS candidate resolution, can improve if the expected address type is specified for each candidate as a candidate extension.
> _____________
> Roman Shpount
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org <mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>