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

Roman Shpount <roman@telurix.com> Tue, 05 February 2019 18:19 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A1D1311F8 for <rtcweb@ietfa.amsl.com>; Tue, 5 Feb 2019 10:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 R03GmkN0gWTF for <rtcweb@ietfa.amsl.com>; Tue, 5 Feb 2019 10:19:19 -0800 (PST)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 66BAB1311E4 for <rtcweb@ietf.org>; Tue, 5 Feb 2019 10:19:19 -0800 (PST)
Received: by mail-pf1-x433.google.com with SMTP id 64so1837591pfr.9 for <rtcweb@ietf.org>; Tue, 05 Feb 2019 10:19:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5C7Wzh1W2jkgNal52qiy3718jGsLLm53TwMcxaUG1jI=; b=q2kGLaBq55xRiugKR0/C+IeJgryuM8x9QjCIwd9nUEJjLXqemV630s+BNKPp5vXvDK mDwNS0BNbb4vJdUGgM1pW/cjMqpFWjJhu7j2MxOXDTm2dVkMw+bJ/lPfxQQz3xxDt01H dFuQBnIcsLx3wc0z0Kh+vV+15skhOAB4QxLCChKd5iy1Wq/wWdyzUs2UrMYaFMR2U8zb mR2ENhScWrQ4pjggIMM7JmZxGGHL8eRnTP3WdvH5xTP4AcHXih6IXWuEFqbJZTcRBtQK 8rYAwYIQBLaud1BAuCShKLT6LfznqPU8sdzUfyDhjDVeYwAQ/4bn8mxLM3DpyCI2ObZa kTDA==
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=5C7Wzh1W2jkgNal52qiy3718jGsLLm53TwMcxaUG1jI=; b=S3LUmLTVjU2LTpR9xdAFV2VLf568WZII6d+HV3MZo+3Fwedq8kpjNppvJJ5zUrp2sG QnU9ep6PSJM6EkmmugFIuZTrYHrm2cr6zm58rhADxbtt+tvE6AQGtoK3YXD0INypHDj7 bAt8txhgaSVWF//zlqgbInHkPbzU7ACsU9FzofvE4DKvXtuNsg2l1oOoAeTlb6QBD7eE DC+P0KcmtTeha5eUU4igLAqKDIjtKOhBNS7lrjtUaSupLl8nqvQ+iB4NutB24mTMrs+Q hCx/GdJw8M8lB6N9cylK90eI55vIckBFb7Qd4qky9O4PuzDKszOcALZ5tPNlqcx0Fz/3 scXg==
X-Gm-Message-State: AHQUAuZuc4XRfHqsdLoPX6tc5fqYyggTL/1m6ES71wLbV8mYYZr2f3xz IHm32Q2wedJVuTKv7RrBsTpiL0JTZGI=
X-Google-Smtp-Source: AHgI3Ia0+ZXEFkbGFM/uf/Lxu7wWrB2j+kAuFQYpYX9UUl0NC/xluV4LBjLr8c0pqaGpVif6u1nqLg==
X-Received: by 2002:a65:6553:: with SMTP id a19mr1321543pgw.267.1549390758510; Tue, 05 Feb 2019 10:19:18 -0800 (PST)
Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id x186sm5095034pfb.59.2019.02.05.10.19.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 10:19:17 -0800 (PST)
Received: by mail-pl1-f181.google.com with SMTP id u18so1846577plq.7; Tue, 05 Feb 2019 10:19:17 -0800 (PST)
X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr6476391plb.55.1549390757224; Tue, 05 Feb 2019 10:19:17 -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> <CAOJ7v-2c7baQ9UUzxxuA41jbNqeOD8SdqJgCTDAUPXwOZ7r_4Q@mail.gmail.com> <CAD5OKxsc4F4DOW6=u3XU5N3NJ4jPx35Q-8WNF_0MGZziy7=b=g@mail.gmail.com> <HE1PR07MB31617DB79BE41B64AECF082693920@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxu7Sjnp6zLo1jxnqS5_3URM6Fj9KrijSLKXERHBqr1Pkw@mail.gmail.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com>
In-Reply-To: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 5 Feb 2019 13:19:06 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtn4TCZCgV_4r17AqUgbFxgk1NjMBNCR0Gcn-67zRJCwQ@mail.gmail.com>
Message-ID: <CAD5OKxtn4TCZCgV_4r17AqUgbFxgk1NjMBNCR0Gcn-67zRJCwQ@mail.gmail.com>
To: Alan Ford <alan.ford@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Simon Perreault <sperreault@jive.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b3e5af058129a5d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/4wIsufOcsUqVxLG4mtJLU-cVpaw>
Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2019 18:19:27 -0000

On Tue, Feb 5, 2019 at 10:03 AM Alan Ford <alan.ford@gmail.com> wrote:

> If that update was to be made, this goes against the text
> in draft-ietf-rtcweb-mdns-ice-candidates-02 which says:
>
>    An ICE agent that supports mDNS candidates MUST support the situation
>    where the hostname resolution results in more than one IP address.
>    In this case, the ICE agent MUST take exactly one of the resolved IP
>    addresses and ignore the others.  The ICE agent SHOULD, if available,
>    use the first IPv6 address resolved, otherwise the first IPv4
>    address.
>

This is obviously not going to work. At the very minimum ICE client should
be listening for connectivity checks on all addresses to which FQDN
candidate resolves, including IPv4 and IPv6. It also should do connectivity
checks to all addresses. Otherwise, if you have two clients, one dual stack
and another single stack, they are not going to see each other, since one
will be listening and sending connectivity checks via IPv6 and another via
IPv4. This is why language about FQDN was removed from mmusic-ice-sip-sdp
-- it was broken.

For ICE to work, you want to include all possible addresses for FQDN in the
candidate list and then proceed with nomination as if they were independent
candidates.

But there’s a bigger problem here, which is how to cope with an FQDN is not
> resolvable. So the intention, as I understand it, is that when these host
> candidates leave the mDNS domain and are thus not resolvable, they will be
> treated as peer reflexive candidates.
>
> But at that point there is no address family information available, so how
> does an ICE agent know to do pairing with these candidates, which requires
> the address family to be known?
>

I do not think this is a problem. For peer reflexive candidates, ICE agent
knows address family/local address/port where connectivity check was
received and the address family/remote address/port from which the
connectivity check was received. Everything, including the address family
is known in this case and agent can proceed with nomination as with any
other peer reflexive candidate.

Regards,
_____________
Roman Shpount