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

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

Return-Path: <juberti@google.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 CCCAC131219 for <rtcweb@ietfa.amsl.com>; Thu, 31 Jan 2019 21:02:15 -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=ham 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 zlQ3M8LHtsQy for <rtcweb@ietfa.amsl.com>; Thu, 31 Jan 2019 21:02:13 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 4B1AE131216 for <rtcweb@ietf.org>; Thu, 31 Jan 2019 21:02:13 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id k7so4713727iob.6 for <rtcweb@ietf.org>; Thu, 31 Jan 2019 21:02: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=AGECSDaObmgXidC19DhPF9AOVX9xM2GQ0+KGyKGTl3A=; b=PAHBp6zwxHORsuLi2xTqIk6aBsZqdvbbJXhK/0Wfl9uLayT8wMeyoQbhDsE/yUCGPq 1suYZ27y3gwuYRp1v2w2L9fxBzk58JminJF7UKATYZulp9ySVFDTEJQ2i9ntNuJG64xw 15qE57rpI0HBH05PmT4tnGdZ0D1QHnF4uO2wvsrbbw0KRK3D4/zC6yB6XOFHr1ef1XtI yred82YanWcWUrJPXzNa1NDNL0txkfPSDHV1fOMgHG9/hqUXT2ELGa/xIkYBwNNOFgw3 6H3ASMgQmO8gBjdikC8Lk/vQuqeuxgtpOZ+zoCtphK3e2H0LD0PU7V5uMkCbvyVj10gR H1jQ==
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=AGECSDaObmgXidC19DhPF9AOVX9xM2GQ0+KGyKGTl3A=; b=EcfVGZZCqxApapl/FhZNramQqd6eFjjzpSCiCLgHxemG4/AwtrKDMizkQyUR0Kf9mI QtT8I4GCSIQzumOfcnX/MKtIcoBpOKLMMWyWiH2Ec+Epp1Kk7RfcqD7rvhOh4K/r0Y20 +FgDJFi3pqsdnQNjB2bKuEpFD8jfymRuJZYMTgh6ZpxDdI4ruUX8564GeEyNbv1vQ6QM tqFiNjU9ixDUl9kK7VReApIddWNm3NYVTG3ODNi1FHxuxqQl17kGrkVqOiF0gGL9SiOt Tjt0nSVZAW5plNy4sbZE9S/U7UOzsnl9okegx4TERRuwieQhL2FTvir6ATPJlJwKQJIy 3woQ==
X-Gm-Message-State: AHQUAuZiuh+csEdm8Gt/t78cAzE3V5j2rQGUP/mqbr3hcJ7zCewUJ6KX N7eH3ahDuukaiFM65yAJ5pEakuA+1nKXNrVuWmeupg==
X-Google-Smtp-Source: AHgI3IaijygWO/TXJ/DxRS8S0ne/F6JIDiVO2TPsEvtkJEnzI5A/HSPczHHeWurh+EUOSG2LeDxuOMnfWXgRanrT1XA=
X-Received: by 2002:a5e:920d:: with SMTP id y13mr20044337iop.95.1548997331943; Thu, 31 Jan 2019 21:02:11 -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>
In-Reply-To: <CAD5OKxuAUaCcO8X+ESoekHMq2Ba5-hviZ08G1Vyg_qSh4mR73Q@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 31 Jan 2019 21:02:00 -0800
Message-ID: <CAOJ7v-0T8gbNtr22MiZzVSsAX8+4ZP-pVueKFVOuSSJLBmv8RA@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>
Content-Type: multipart/alternative; boundary="000000000000bb35320580ce0b7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/WfgQ_CcxtB8oF845iVvVub08iMo>
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 05:02:16 -0000

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