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

[Roman Shpount <[e-mail]>]

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