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

Justin Uberti <juberti@google.com> Fri, 01 February 2019 19:39 UTC

Return-Path: <juberti@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7613F1312BC for <mmusic@ietfa.amsl.com>; Fri, 1 Feb 2019 11:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.641
X-Spam-Level:
X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CtM2n_6HRh2 for <mmusic@ietfa.amsl.com>; Fri, 1 Feb 2019 11:39:13 -0800 (PST)
Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCB91312C1 for <mmusic@ietf.org>; Fri, 1 Feb 2019 11:39:13 -0800 (PST)
Received: by mail-it1-x12f.google.com with SMTP id a6so11504236itl.4 for <mmusic@ietf.org>; Fri, 01 Feb 2019 11:39:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xcHBuDlh3EaXWoDoQmxZGhJzH/B1FkmLsOZnDiinlzA=; b=JWD8w/vnlAl1mq5fm18raSjveDSjArWqukzE9aNjfmaExr9wQnI30liSDWLQukzyXu p+js2c8FapOMdsE7mf5TeRrlbaS/tg7MAIxVI68mruQDhgPZcrKwHmdztoOj6iolG/RN gnhcp6C/iZEPLD2MT4SGBR6HaRITdmAgZAF1QMo9jD+UNBsDkAvkH6/MLpxVzAIWP+pz NoQdEJE4OEWiT7OjTyqIjTmfQWu3RHDNTlXpRvtyo8s2jtqWeHpnqvrXygD/vOLRjfdF qBpnTHsuxmR31Sn+2hc05xJe5uuqo52scH2AJ+s0QU4LCvfhuE1YFqf7F4l8a29U7IQf uliw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xcHBuDlh3EaXWoDoQmxZGhJzH/B1FkmLsOZnDiinlzA=; b=f1ocAhUNVAbSahGW3hm1bWl8InwgThFyF6o7GSzF0wwicMYmDLkc03+bWI+B4e6mfj uUjhq0wUjk7tWcJzDKKZQJls8ak3mRZovsuOcnzGf0y+MVB4yv9ykNEuUX1OinH5he4n bAmENibqzqvowc0a43ktIMJW4ZGVS0Pc/pqFD0pMgG63jkUBYgx77ENIHIggvez+WUaF h/VrHtvhgHYNzeANS4FGTfkpbJvzAQlx8V2Qhzv8qYpzkCrtdqlceU6+LycbQVpt5ZSh Dg+MkhBsvvkjKHvD+/4nC4oeTOyLbE7etpwgFO1J1Ws2tBwIWEGyjmvLk8fz1J9gqjiM 2BbQ==
X-Gm-Message-State: AJcUukd2dx1vx9Sb5+2LcF9Uopf4AiIuO7xr5q6CVp3nQSiFD9FRlWIb YAUezO110XUhPCcTBitomULWQcRvmOx+mrOfDlyNfg==
X-Google-Smtp-Source: ALg8bN4SUTNQTegwlDqtK/xlWF9ST6S2irLSHYUmeWoDH/TSNHpfJ8Dwb2RJj9JY7R0GaJiRUYxYu0kalmAZlxONFmw=
X-Received: by 2002:a02:94eb:: with SMTP id x98mr25051601jah.88.1549049952060; Fri, 01 Feb 2019 11:39:12 -0800 (PST)
MIME-Version: 1.0
References: <CAD5OKxuGEPccJUJ1E0bSmz9RW6CWhhSqW+Dke1Cywrjp-dvaoA@mail.gmail.com> <874l9ousuk.fsf@hobgoblin.ariadne.com> <CAD5OKxut+Y8NnL2FbFQkubU-8up4eu6F9hOxs-8oBOJoCnTQwg@mail.gmail.com> <CAOJ7v-2GC2UWBaqSccZh1MKg6E93NrNKQJagzMCOfuE6SxuptA@mail.gmail.com> <CAOJ7v-2ZWxDFAtfoXTB4OsfJBAaFFqZ1jt0SSCCm4Qi3Qqfj6g@mail.gmail.com> <CAD5OKxuAUaCcO8X+ESoekHMq2Ba5-hviZ08G1Vyg_qSh4mR73Q@mail.gmail.com> <CAOJ7v-0T8gbNtr22MiZzVSsAX8+4ZP-pVueKFVOuSSJLBmv8RA@mail.gmail.com> <CAD5OKxtqxcqrQGCWc_2L1np9ftk_Q=prU3MMXk7Y+wbLCq0rYA@mail.gmail.com> <CAOJ7v-1MXjLtBKJ8gN4nVm-Z9m0HB=ye9E6Wcm5zeOx5y2zkSw@mail.gmail.com> <CAD5OKxuZPX3DbDEEVXbVamHynazJkv5G6CDMqMPmdMwiW4SNdg@mail.gmail.com>
In-Reply-To: <CAD5OKxuZPX3DbDEEVXbVamHynazJkv5G6CDMqMPmdMwiW4SNdg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 1 Feb 2019 11:39:00 -0800
Message-ID: <CAOJ7v-2c7baQ9UUzxxuA41jbNqeOD8SdqJgCTDAUPXwOZ7r_4Q@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: "Dale R. Worley" <worley@ariadne.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>, Simon Perreault <sperreault@jive.com>
Content-Type: multipart/alternative; boundary="000000000000224ef80580da4c45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/xcRDZCV4uYef2Li_MNGFSk6KMCc>
Subject: Re: [MMUSIC] [rtcweb] What goes into c= line address when FQDN is used for the default candidate?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Feb 2019 19:39:18 -0000

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 <roman@telurix.com> 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 <juberti@google.com> 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 <roman@telurix.com> 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 <juberti@google.com>
>>> 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 <roman@telurix.com>
>>>> wrote:
>>>>
>>>>> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti <juberti@google.com>
>>>>> 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
>>>>>
>>>>>
>>>>