Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?

[Justin Uberti <[e-mail]>]

This has all been discussed at length in rtcweb and I don't think any
significant changes are needed, although I tend to think that we should
restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only
thing not in alignment at this point in time.



On Fri, Feb 1, 2019 at 11:18 AM Roman Shpount <[e-mail]> wrote:

> Most likely mDNS draft will need to update RFC 8445 to specify how ICE
> nomination procedures are modified, when mDNS is used as candidate-address.
>
> As far as mmusic-ice-sip-sdp is concerned, one option would be to allow
> FQDN as candidate-address. The guidance for handling FQDN in
> candidate-address should be updated from RFC 5245 and should specify that
> FQDN names should be ignored. mDNS ICE draft then will update ice-sip-sdp
> and specify that mDNS FQDN should be handled according the procedures of
> this draft.
>
> Another option, which I think word work better with existing
> specifications is to add a new candidate type -- mdns. This way, instead of
> magic DNS suffix, candidate type will be used to determine that this
> candidate should be handled differently. I do not think MDNS candidates can
> be used for anything except host candidates, so making then a special
> candidate type might be the least painful option. It might even make sense
> to make separate types for IPv4 and IPv6 MDNS candidates which would save a
> DNS query for each candidate.
>
> Regards,
> _____________
> Roman Shpount
>
>
> On Fri, Feb 1, 2019 at 12:39 PM Justin Uberti <[e-mail]> wrote:
>
>> I understand there were questions about the general case (e.g. regular
>> DNS names), but how do we plan to reconcile this removal with the need for
>> mDNS hostnames?
>>
>> On Fri, Feb 1, 2019 at 9:09 AM Roman Shpount <[e-mail]> wrote:
>>
>>> Hi Justin,
>>>
>>> I agree regarding #1 in theory, even though in practice a lot of (most)
>>> devices will not accept FQDN in either c= or ICE candidate.
>>>
>>> Regarding #2, mmusic-ice-sip-sdp was updated (
>>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1
>>> ):
>>>
>>>    <connection-address>:  is taken from RFC 4566 <https://tools.ietf.org/html/rfc4566> [RFC4566 <https://tools.ietf.org/html/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.
>>>
>>>
>>> Specifically, support for FQDN names there was removed due to RFC 8445
>>> implementation issues. I believe Simon Perreault suggested this change.
>>>
>>> Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>
>>> On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti <[e-mail]>
>>> wrote:
>>>
>>>> My recommendation here would be that we do c=IN IP6
>>>> 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6
>>>> depending on which type of address is being wrapped.
>>>>
>>>> Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for
>>>> FQDN in the c= line.
>>>>
>>>>      unicast-address =     IP4-address / IP6-address / FQDN / extn-addr
>>>>
>>>>
>>>> Re #2: Quoth 5245 <https://tools.ietf.org/html/rfc5245#section-15.1>:
>>>>
>>>>    <connection-address>:  is taken from RFC 4566 <https://tools.ietf.org/html/rfc4566> [RFC4566 <https://tools.ietf.org/html/rfc4566>].  It is the
>>>>       IP address of the candidate, allowing for IPv4 addresses, IPv6
>>>>       addresses, and *fully qualified domain names (FQDNs).*  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 MAY be
>>>>       used in place of an IP address.  In that case, when receiving an
>>>>       offer or answer containing an FQDN in an a=candidate attribute,
>>>>       the FQDN is looked up in the DNS 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.  If the DNS query
>>>>       returns more than one IP address, one is chosen, and then used for
>>>>       the remainder of ICE processing.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount <[e-mail]>
>>>> wrote:
>>>>
>>>>> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> We can however all agree that "c=IN IP6" is busted:
>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=927309
>>>>>>
>>>>>>>
>>>>>>>>
>>>>> I guess one way to interpret this that each address should have a MDNS
>>>>> alias. So, if you are dealing with dual stack host, it should provide two
>>>>> MDNS candidates, one of which is IPv4 and another IPv6. The c= line should
>>>>> specify FQDN for one of those candidates and specify the type (IP4 or IP6).
>>>>>
>>>>> There are two problems:
>>>>>
>>>>> 1. There is no way to know which address type is in the
>>>>> candidate-address when FQDN is used there. Guidance in ice-sip-sdp is
>>>>> talking about the presence of column in IP6 address, but this definitely
>>>>> does not apply to FQDN. It would've been better to specify something like
>>>>> local4 and local6 as FQDN suffix in MDNS alias to specify the
>>>>> candidate-address type so that correct DNS request can be issued.
>>>>>
>>>>> 2. A lot (if not most) SDP/ICE implementations do no support parsing
>>>>> FQDN in candidate-address or c= line. This might create interop problems
>>>>> since RFC 5245 specified that candidate-address is an IP Address.
>>>>>
>>>>> Regards,
>>>>> _____________
>>>>> Roman Shpount
>>>>>
>>>>>
>>>>