Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?

Roman Shpount <> Thu, 04 July 2019 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B9BC1201A0 for <>; Wed, 3 Jul 2019 18:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FaNaJzMrszZO for <>; Wed, 3 Jul 2019 18:15:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8279012010F for <>; Wed, 3 Jul 2019 18:15:15 -0700 (PDT)
Received: by with SMTP id s27so2075734pgl.2 for <>; Wed, 03 Jul 2019 18:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Sj9FVzTDGbFfpHphlVNDdgQMHAYfbmoEKVSZ5d5cbg=; b=JWWyCFnkpUUqKap8kPBQoWPqSvahaWJks5q14lgKSACMEkUgspPTjzXiGxgZ6Pr5It RHKK4Xfj19QP+Mm5YaeSuu23nzYfzKAoBvWxGF/1K+fkoQfV8MTKFPWJf8XzVz6YJ+yf TMdp5CsCa4j8NcI2yaAh9irFiA4vhRTT6FiHG0I/vE/W9kGLSv81+qpxT+8SYC5COODW 5RMBu9ZrvkcUZTzMpAS382qMFHeXUGItixNJK4VVSjAFKvvD9Bc16FGgN5UpIvVsd/J0 ReiazK1g71WsphGRKymS5kfhen3gtVxn7CuF1kw9bUccu0hh2ig0F+wZBg2XIS5tlAjO nXJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Sj9FVzTDGbFfpHphlVNDdgQMHAYfbmoEKVSZ5d5cbg=; b=HItiL1uwx22uGHv2Qmzdi5qsQ7AhDK0tYVTTr0twBP9tqYRhhLF/ORKW1kP2P3Aynp VFjE9uGJqBJXdMQ8zd3FvnPQrTMC7n4tKzIDxNLlk2AvcHHfBWZbwQ7Kn3+t6ddiUKOL 88gL4qhqENoJ8FlGzlOW3P3bAQo5PG/k0Qd/EhSnQeN/W11IdXmo4sd0IlvSYDXmQ3AS 5peieTrAXKmJ2oIZEn27PQxWSTIrDNdvhklDn2QrkfKFu6kCadl6c8VfaNIi7Lvou08M K5vyB+dB2qHyo5z5wPfsfKzRLB5riK30PbGAru/yHB1sp8oJyp2J4AZYoiP5MQa1daFt 1KtA==
X-Gm-Message-State: APjAAAUvLlZ7KA/dy3QW31dAqHaqNikBcourilrPBrkgAU5iY5H2KUiB Hgn37JV7VRNoRV+zaz3/yAc+NmRo
X-Google-Smtp-Source: APXvYqzXQidbts+Zg2UlGMVX/MJrtOPpVKZeZkBsmvl+sq7dSjcgb3KU5kp3ikmfhzeOQBi/GqCqIQ==
X-Received: by 2002:a17:90a:f498:: with SMTP id bx24mr16374834pjb.91.1562202914583; Wed, 03 Jul 2019 18:15:14 -0700 (PDT)
Received: from ( []) by with ESMTPSA id u21sm7172322pfm.70.2019. for <> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 18:15:13 -0700 (PDT)
Received: by with SMTP id c14so2162483plo.0 for <>; Wed, 03 Jul 2019 18:15:13 -0700 (PDT)
X-Received: by 2002:a17:902:20c8:: with SMTP id v8mr45901592plg.284.1562202912728; Wed, 03 Jul 2019 18:15:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Wed, 3 Jul 2019 21:15:03 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Justin Uberti <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000ae2fdf058cd0b5f1"
Archived-At: <>
Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jul 2019 01:15:19 -0000

This direction was taken since mmusic got no feedback regarding the
specifics of FQDN support. I did try to get mdns authors, including you, to
participate in the discussion, since I was afraid this can be a problem,
but no one responded at that time.

As it stands, there are significant issues with just putting FQDN in
candidate. The gist of the issue is that due to things like DNS64 there is
no way to enforce that FQDN will resolve to the same address family to
which FQDN was originally pointed to. So, end points will end up either
with different address families or with multiple addresses for the same
candidate even when FQDN in candidate originally only pointed to a single
IP. Connectivity checks will likely succeed on some of those address pairs,
but figuring out priority for the candidate pairs becomes confusing and
under-specified. No one wanted to discuss or deal with this before
ice-sip-sdp was published so the current language was put in place.

I know the browsers are trying to address what they perceive is a
significant issue, but I would think that current mdns draft is fairly raw
and turning this option on is likely premature. It might lead to multiple,
non-backwards compatible versions of this feature.
Roman Shpount

On Wed, Jul 3, 2019 at 8:58 PM Justin Uberti <> wrote:

> Hmm, that's unfortunate. I think this is a mistake, given that we are
> about to throw the switch to enable mDNS for 100% of Chrome endpoints;
> Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this
> extension spec is written.
> ice-sip-sdp isn't published yet, so it seems an update to that document
> could still be a possibility. If that's not an option, putting forth #1 as
> a specific extension that allows FQDN candidates to be generated in certain
> situations seems like the right path.
> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <> wrote:
>> Part of the problem is that mmusic have decided to punt on the FQDN
>> support. In the current mmusic-ice-sip-sdp the final language that was
>> included:
>> <connection-address>:  is taken from RFC 4566 [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
>> generating local candidates MUST NOT use FQDN addresses.  An agent
>> processing remote candidates MUST ignore candidate lines that include
>> candidates with FQDN *or IP address versions that are not supported or
>> recognized.  *The procedures for generation and handling of FQDN
>> candidates, as well as, how agents indicate support for such procedures,
>> need to be specified in an extension specification.*
>> So, at this point we have two options:
>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and
>> define how FQDN candidates generated by mdns are handled
>> 2. write a new draft in mmusic which defines FQDN handling
>> In any case some sort of mmusic discussion is needed to reconcile this.
>> Best Regards,
>> _____________
>> Roman Shpount
>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <> wrote:
>>> The problem this draft is trying to solve is fairly RTCWEB-specific. If
>>> there are individual issues to resolve, we can send them out to mmusic for
>>> discussion, but AFAIK no changes to existing ICE specs are needed.
>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <> wrote:
>>>> Hi All,
>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?
>>>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb.
>>>> Also, there are significant interop implications for this draft
>>>> between browser and non-browser end points which probably warrant larger
>>>> discussion outside of rtcweb group. I would think mmusic would be a much
>>>> better place for this draft. I know there is an incentive to complete this
>>>> draft quickly but this has a potential to break a lot of things (it already
>>>> did break interop with almost every existing ICE implementation).
>>>> Regards,
>>>> _____________
>>>> Roman Shpount
>>>> _______________________________________________
>>>> rtcweb mailing list