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

Agreed that an explicit reference to MDNS would be good.
DNS resolution can be used for both candidates as well as STUN/TURN server
names.
The proposal so far is to ensure that MDNS be supported for candidates.

Le mer. 18 juil. 2018 à 10:20, Justin Uberti <juberti@google.com> a écrit :

> Note that we are going to discuss the particulars here in the mmusic WG
> meeting on Thursday.
>
> On Wed, Jul 18, 2018 at 7:17 AM Justin Uberti <juberti@google.com> wrote:
>
>> 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 theIP
>> address of the candidate.  When parsing this field, an agentcan
>> differentiate an IPv4 address and an IPv6 address by presenceof a colon in
>> its value -- the presence of a colon indicates IPv6.An agent MUST ignore
>> candidate lines that include candidates withIP address versions that are
>> not supported or recognized.  An IPaddress 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 <ted.ietf@gmail.com> wrote:
>>
>>> On Tue, Jul 17, 2018 at 4:46 PM, Peter Thatcher <
>>> pthatcher=40google.com@dmarc.ietf.org> 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 <youennf@gmail.com>
>>>> 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=
>>>>> 40google.com@dmarc.ietf.org> 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
>>>>>> <ekr@rtfm.com>> wrote:
>>>>>>
>>>>>>> It seems like this is something one could A/B test and measure
>>>>>>> connection rates. Has someone done so?
>>>>>>>
>>>>>>> -Ekr
>>>>>>>
>>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> rtcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>