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

Roman Shpount <> Thu, 04 July 2019 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2361D12021F for <>; Thu, 4 Jul 2019 12:27:09 -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 v1lFHUD9sAyw for <>; Thu, 4 Jul 2019 12:27:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4E611201EF for <>; Thu, 4 Jul 2019 12:27:06 -0700 (PDT)
Received: by with SMTP id c13so3262007pgg.3 for <>; Thu, 04 Jul 2019 12:27:06 -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=SM+dQ/GViR0w8uH2+QjD7Iltd3C3jd8zMRLL0SoIjpU=; b=puG2uLCf3SG6lwvpC0UZpKaxzIJxLXf600Y2RojTpL69d2AHzQ622SDLy9x6gSCHqx OGOChajLeSBn0xrrA+il9YanjN3cboTIJQv0D6Sbtw3IToyOOoBpnKhMVhAE5J/de2qL hXb95e8qpDIcBwd1a2UxHzfY2Q33Beo+JkRm/YAe2LyeEBtusjbgxlBd6wBQkYxjgXjv MLccmw/oRLsuw/4iPrIL0vHBGRbyKBmRiXgpcIjoUxdUTZm/4S93bkooch70QpiditIW i6/hwU5/3ZXpKfw8VsUAHzViYKqcAG7wLP0rOp4ackhJDdjL6VmdkFn3K7DaOExtrwEA rGXw==
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=SM+dQ/GViR0w8uH2+QjD7Iltd3C3jd8zMRLL0SoIjpU=; b=AG9P2iu+kjChRYnLTFC3q6ZIQComn2AccupmQd60iUwxAUdHoeYAv4VeGnBZfB21RQ AazSodpxVAGShV1mI4ApmLQkldD+/0pZasmDuj75mJFBaX9V63o+manuYin8SJcV9ZDd J5xuIqSUSL0ibaV+tp7LLK+L05+gTavyoC2Fx+yqgEOL9ZEHLVt3rWSwvoJxmI6y/Vev YU25NyMzbQ8ON1DH3GlCEWqf2QbLEtWn1GhHHU+KhWSDmBvxa/phLAqOrSxLt7DniEsx fqzGYfOUPsWr53Y+75/pCSAfTN0qRvHs/etB4CyC+r77WjOR2bImfkRx1PV12kuUKQUe 8fvg==
X-Gm-Message-State: APjAAAW3kWgyUS/cCuMDY08a4ThpfoQFm2Vis12xohaiYnwXNPrRXY2l LZDhJ8PmGuf0KQKZNIbhYKvI6wCXSjk=
X-Google-Smtp-Source: APXvYqwaVTUs1Ystw/qHJ/STyVJL6m1mSTdh4WRtXlrgpkqOKz+RFMm/GYnPlqfmzonYoR3KF0uM/w==
X-Received: by 2002:a63:f146:: with SMTP id o6mr107528pgk.179.1562268425683; Thu, 04 Jul 2019 12:27:05 -0700 (PDT)
Received: from ( []) by with ESMTPSA id j11sm8694145pfa.2.2019. for <> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 12:27:04 -0700 (PDT)
Received: by with SMTP id k8so3491672plt.3 for <>; Thu, 04 Jul 2019 12:27:04 -0700 (PDT)
X-Received: by 2002:a17:902:bd0a:: with SMTP id p10mr51399591pls.134.1562268423934; Thu, 04 Jul 2019 12:27:03 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Thu, 4 Jul 2019 15:26:55 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Nils Ohlmeier <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000073d8a9058cdff6e6"
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: Thu, 04 Jul 2019 19:27:09 -0000


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

; 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