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

[Roman Shpount <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>