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

Roman Shpount <roman@telurix.com> Fri, 01 February 2019 17:09 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 7FB31130934 for <rtcweb@ietfa.amsl.com>; Fri, 1 Feb 2019 09:09:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 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, URIBL_BLOCKED=0.001] 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 G5LIelEazw5M for <rtcweb@ietfa.amsl.com>; Fri, 1 Feb 2019 09:09:17 -0800 (PST)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 7DAF7131065 for <rtcweb@ietf.org>; Fri, 1 Feb 2019 09:09:17 -0800 (PST)
Received: by mail-pf1-x430.google.com with SMTP id c123so3524239pfb.0 for <rtcweb@ietf.org>; Fri, 01 Feb 2019 09:09:17 -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=YZ0oKaTF9P548qmCWeUeJGbKicw6Jis3S2Z9XYykzzo=; b=0DzLiuCIz9fPI6qJJjKsdsWeSBflPGpn61msvwtHNaxyMSvQAx8Te9gnm0Nm6Tc9vq ADr2qBubBLptPryv2uCGZF7MmIyihZQmIG9Msie1jQ63X3qimuqzDvFAKo8h+jizZPSe Aqu6dyAnhV/JV2pKCxXLL+xFZAPeLTolssWbWuyiSb0I2cbKcbfPA1ot85K6slTfs5JW PSC8HhIrWFnMzmD5/bFTYekMxWPjRoYzeJNZV4YojhDClHTDU8k9h5RsEUd46EdWdJmg r1SjejlVTTTTrRaLlxNCSWHqEeB+H0sZuGuKhQm8CPh6esL6tpZ0Eku7J4CRLbmf6NF9 iNrg==
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=YZ0oKaTF9P548qmCWeUeJGbKicw6Jis3S2Z9XYykzzo=; b=dHyQ4jycmfeNEqRbmN8hui2dpYQJh62arOB5KAIV/w5EQrTssz2Yh4mO3lVwSIzbAe 9MnlRE1JzGds9+ffYyLqTPdaWVY2CTHrv9Z2qaq+m90VHsKByWQuKvYgA+SC2PskGIgQ 0jfLSXn0CEhl6qrpHaIDpteVfPaq3MpnVwzT+n3AkBhZGpflNLY4Kv1BX6ZjionaGb4J wLFWjPvEYF97DJcqSAt8qHOPFNYVL4a73icyPoUf5GomjVIehjQo+3WA4gVRf1Hmmv2l muEppr6N+EzWwih2y6ERyx6O27y55XHob7l8pEeyzpupfXWfa9oHFkemHyMKJzYKGhGA 3U2g==
X-Gm-Message-State: AHQUAuYdtPjSqeipuFjZAhzANwxUfEZuKg2Btoxyo4ou6VdAkAGqeeka xvjE2oRnsNxn8Af6LnV4c1cElSniiRE=
X-Google-Smtp-Source: AHgI3IYnpr/16IPQ6yLvI8QizZbJOS/pFfhVzvmppIxKl/gWNCnhyYzADHnZNmceB4PuAl62fVb6Tw==
X-Received: by 2002:a63:9749:: with SMTP id d9mr2900925pgo.415.1549040956754; Fri, 01 Feb 2019 09:09:16 -0800 (PST)
Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com. [209.85.210.177]) by smtp.gmail.com with ESMTPSA id u12sm3434123pgo.52.2019.02.01.09.09.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 09:09:15 -0800 (PST)
Received: by mail-pf1-f177.google.com with SMTP id g62so3488988pfd.12; Fri, 01 Feb 2019 09:09:15 -0800 (PST)
X-Received: by 2002:a63:b4c:: with SMTP id a12mr3064102pgl.131.1549040955470; Fri, 01 Feb 2019 09:09:15 -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>
In-Reply-To: <CAOJ7v-0T8gbNtr22MiZzVSsAX8+4ZP-pVueKFVOuSSJLBmv8RA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 1 Feb 2019 12:09:05 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtqxcqrQGCWc_2L1np9ftk_Q=prU3MMXk7Y+wbLCq0rYA@mail.gmail.com>
Message-ID: <CAD5OKxtqxcqrQGCWc_2L1np9ftk_Q=prU3MMXk7Y+wbLCq0rYA@mail.gmail.com>
To: Justin Uberti <juberti@google.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="000000000000e4b8c00580d833f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/-DVK40K_rccp6Ncqh0qxrpJ0_s4>
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: Fri, 01 Feb 2019 17:09:20 -0000

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