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

[Qingsi Wang <[e-mail]>]

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