Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03

Nils Ohlmeier <> Mon, 08 July 2019 23:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58BCF1203AF for <>; Mon, 8 Jul 2019 16:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MWTiqM2IsCGS for <>; Mon, 8 Jul 2019 16:55:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EDE61203CC for <>; Mon, 8 Jul 2019 16:55:40 -0700 (PDT)
Received: by with SMTP id b13so3754598pfo.1 for <>; Mon, 08 Jul 2019 16:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AYzL5Oe57Vg6Uuwt7ZFz0JyvlrS2HPLkmohT2liOIeg=; b=Mn1xGIIk8ILzYQnciYh6fRcI1KZiRE0kkCJ5W26ZcDYwtrXcDQBjrXkxINYSetlJTt wAt/ZW/QC1xRJUB1wRC+MjOHbPkeTPNMmVJXOKyxm0Xioihn8D37ULCiQrfQ0s5aNDzG tPNFmCIEfOkvVwdb6Fe7HLT3LbElZbO/Tbn8k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AYzL5Oe57Vg6Uuwt7ZFz0JyvlrS2HPLkmohT2liOIeg=; b=qK5H38UY/crGWA4kvo8nbPY1Nm0dTI8qM6gZEFCYT4IJt/vl1o9Z5a14GFXt/5SOMX Hq7AoCrLxs/Ek888ei7FMSjPFzIgDN2T4FoJBTZI53VYUBAs/driSkut9BUqhrT4L86F DHmd9hoR3HHzS25asDXnITu2bOPUTwVp5K0cytw18PhoKltbnCnvR+DCTiEBcXDOa52D VfoKlL1079yiexZiodI7lhM1wjHHhBu1XgvO49fWMU9bZ9jYWNV9MHa++L938iaxe5HR gddfhW0deqlo0x/b4uwWsFSD0XliNpKWOCIZLz0P5zeKLa8rmWHBC+8yUwBA6WuIv48C QO1A==
X-Gm-Message-State: APjAAAVMEGXkGHFYRx31U8IvQdLG94DqFvJMpX3o8Gm6227aXJBaz9Bp P1OQnpikfcvOz7jGZhFZZYsfag==
X-Google-Smtp-Source: APXvYqy/d1l+rubFGdv7mABB6xVVlIO53ZWFx0/CxSh9PkBBSBxmyvmBRSqAgTyFpMuk5xqRiRRPRA==
X-Received: by 2002:a63:1847:: with SMTP id 7mr27587428pgy.204.1562630139580; Mon, 08 Jul 2019 16:55:39 -0700 (PDT)
Received: from ?IPv6:2620:101:80fc:224:7cf2:850f:6b10:755e? ([2620:101:80fc:224:7cf2:850f:6b10:755e]) by with ESMTPSA id 195sm10091286pfu.75.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 16:55:38 -0700 (PDT)
From: Nils Ohlmeier <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB51A1D2-B9FC-4BB8-B629-68055F676D1A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 8 Jul 2019 16:55:37 -0700
In-Reply-To: <>
Cc: "" <>
To: Roman Shpount <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03
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: Mon, 08 Jul 2019 23:55:50 -0000

Hi Roman,

I know that not being able to handle FQDN in c-lines is a bug on the Firefox side.
And we are working on it to fix it: <>

But my main question is: why does the draft right now recommend to use the mDNS FQDN in the c-line, rather then a fake IPv4/IPv6 address?
I fail to see the advantage of using the FQDN and it appears to cause more interop issues.

  Nils Ohlmeier

> On 4Jul, 2019, at 12:26, Roman Shpount <> wrote:
> Nils,
> When writing ice-sip-sdp we have considered two possible options when using FQDN in ICE candidate lines:
> 1. Same FQDN as in default ICE candidate
> 2. IPv4/IPv6 address values ""/"::" and port value of "9"
> To deal with both, ice-sip-sdp specifies, that when verifying ICE support, both options should be accepted.
> Since RFC 5245 provided no guidance regarding handling FQDN in default candidate, both options would likely cause ICE support verification failures. Using FQDN in default candidate also raised the question of address family and address type in c= line since neither is specified in the ICE candidate. 
> This being said, FQDN in c= line is allowed by RFC 4566: 
> connection-field =    [%x63 "=" nettype SP addrtype SP
>                          connection-address CRLF]
>                          ;a connection field must be present
>                          ;in every media description or at the
>                          ;session-level
> ; sub-rules of 'c='
> connection-address =  multicast-address / unicast-address
> unicast-address =     IP4-address / IP6-address / FQDN / extn-addr
> Not being able to handle FQDN in the c= line is technically a bug.
> Best Regards,
> _____________
> Roman Shpount
> On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier < <>> wrote:
> Hello,
> I have concerns regarding the current recommendations in draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP addresses in the “c=“ lines.
> Section recommends to use mDNS for the connection-address. I think we should reconsider this advice as some SPD parsers handle parsing failures differently depending on line type.
> In case of Firefox a parsing failure for the connection line is treated as terminal failure. Where parsing failures for a= lines are expected, as these might contain unknown new features.
> Section 4.3 mentions that hostnames in ICE candidates can result in ICE failures, but it does not cover backward compatibility in regards to the c= line.
> My recommendation is to change the draft so that it recommends to always use a fixed value, for example IP6 ::1 in all c= lines, if mDNS is in use. Obviously it could also be recommended to use an IP4 address instead. The important point is only to use the same IP consistently in all c= lines and across all instances.
> I think the advantage of this is better backwards compatibility, and it will not reveal any more details about the user agent compared to using mDNS names in c= lines.
> Best regards
>   Nils Ohlmeier
> _______________________________________________
> rtcweb mailing list
> <>
> <>