Re: [rtcweb] IP handling: Using mDNS names for host candidates

[Christer Holmberg <[e-mail]>]

Does that mean that RTCWEB is actually going to reference ice-sip-sdp and ICEbis (instead of RFC 5245)?

Regards,

Christer

From: rtcweb [mailto:[e-mail]] On Behalf Of Justin Uberti
Sent: 18 July 2018 10:18
To: Ted Hardie <[e-mail]>
Cc: RTCWeb IETF <[e-mail]>
Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates

Yeah, I think we just need to emphasize that the FQDN can be a mDNS name. Here's my current suggestion for updates to S 4.1 in ice-sip-sdp<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-21#section-4.1>:

<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.  An IP
address SHOULD be used, but an FQDN (including a mDNS [RFC6762] name)
MAY be used in place of an IP address.

In the case of receiving an candidate containing a FQDN, the hostname is looked up via DNS or mDNS as appropriate, first using an AAAA record (assuming the agent
supports IPv6), and if no result is found or the agent only
supports IPv4, using an A record.



On Tue, Jul 17, 2018 at 3:11 PM Ted Hardie <[e-mail]<mailto:[e-mail]>> wrote:
On Tue, Jul 17, 2018 at 4:46 PM, Peter Thatcher <pthatcher=[e-mail]<mailto:pthatcher=[e-mail]>> wrote:
Where is the right place to comment on draft-mdns-ice-candidates?

I looked at it from an ICE WG perspective, and it seems to be that since (in RFC 5245), the candidate address can be a FQDN (section 15.1) you don't need the special steps you have in section 3.2, because a .local address is a FQDN (isn't it?).

The use of a .local signals that this is a special use name within the context of multicast DNS (RFC 6762).  One key difference there is that the uniqueness of a standard DNS name is derived from the hierarchical delegation of the DNS.  Uniqueness in MDNS is achieved using a local probe and announce method.  As Harald pointed out in the room, there are some latency consequences to that; those might be avoided by generating probable uniqueness in names via the UUID mechanism, but that still need to be worked out.  That, I think means the work in 3.1 is definitely needed.

I think the only novel thing would be to perhaps make it clear that mDNS should be used for the name resolution.

You might treat the special steps as redundant (since .local should signal mDNS), but I personally think it is helpful, because it discourages coalescing with standard DNS responses (which is permitted by 6762).

Just my personal opinion.

Ted




On Fri, Jun 29, 2018 at 6:07 PM youenn fablet <[e-mail]<mailto:[e-mail]>> wrote:
A draft describing the Safari/WebKit approach is available at https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt

Eric, can you precise the kind of information you would like to have?
Some testing has been done to validate the approach but I do not think this is representative of the actual state of the affair. Safari/WebKit is not gathering any related statistic..

   Y

Le ven. 29 juin 2018 à 11:10, Justin Uberti <juberti=[e-mail]<mailto:[e-mail]>> a écrit :
I believe such data will be forthcoming from the Safari team. We are also working on this.

On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <ekr@rtfm..com<mailto:[e-mail]>> wrote:
It seems like this is something one could A/B test and measure connection rates. Has someone done so?

-Ekr
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb