Return-Path: 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 681FE12D4EF; Tue, 5 Feb 2019 07:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8-mKvWZFfNRI; Tue, 5 Feb 2019 07:03:50 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D2C5B128CF3; Tue, 5 Feb 2019 07:03:49 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id z26so2882119lfj.6; Tue, 05 Feb 2019 07:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=owExOrfkKjs/wCjN5kHmH+mHynDVt0DON6xDWz+TcX4=; b=NU0CrmYinnNr9NHoiZiltcBGCDdDvbfIMQ65nYAO3vbkG6OOiEKdIwYhML2xKd00jB pO5b4csuQ0CaD1A0kGzHW5RtGYd8LwBewWM61bPrygAXOV6LWcVVyy+0J/6UB8E94H9i 4uAiAd+YklyX6oGQFRedodTWMQTxyMdlJTLNcbLIV/WBITf/YFdk42VICI93j1A7RC2U opvhATMyLkwyLb4zD7xNPJ5HXLieoHD2SltiZ0FgkcN6Drpw4UbpCoW2hcUAbiVToahw tKWQamyphicThCOCY+f4gnXcj/KLEWdVgAuIlSqLdcgAPKyP+wuobDj/573rJEXjWzUq rsDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=owExOrfkKjs/wCjN5kHmH+mHynDVt0DON6xDWz+TcX4=; b=TLw16q+Yz4t0HP8/YmnTukVQjM8YDWDA5HSaz/XlTuZPoRHo2XH+GVx07PFpwTmxU+ zU6jTpDnbyIJinZ0LyfxQFXZha4RD1q6LpAvnYGyk5PX0XTMG/xXRjIRLpOCPR70r3Cp jHbOktZQFygc97bBvVFoP0+yNkxm0MhFrWw9xEJ+C+jTyufSqrx7PTAwoc9f/MgbHXfY HNXYO0STbrXQ7/A75hcIIAY1FymWamLfwBUhURP9FyYhpeg/k2Bvjuzyha++uI3qZgGE T/lCfz6RCSQUd1AVcdtrEfF6jxpJVUdkOAD1CXvLrAMccTLTRlEyC0BrM6VmkTb5YgIN RBAg== X-Gm-Message-State: AHQUAua0Ujj3VsusSDARwxg8yW1OFUTVYrXQyJVf2VlgAAoxGCEKNArW fibgl5ZDSCC0WufSl6f5S5s= X-Google-Smtp-Source: AHgI3Ibi4gH6z0SIjn2NjhT129hNKcBq49ekleyaPpz9sL6MAsQ5RdA73wUJwJ6wmSVKJVvl4TXghw== X-Received: by 2002:a19:d1d2:: with SMTP id i201mr3365742lfg.136.1549379027942; Tue, 05 Feb 2019 07:03:47 -0800 (PST) Received: from [192.168.1.66] ([31.185.193.196]) by smtp.gmail.com with ESMTPSA id y24-v6sm3271987ljd.20.2019.02.05.07.03.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 07:03:45 -0800 (PST) From: Alan Ford Message-Id: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 5 Feb 2019 15:03:41 +0000 In-Reply-To: Cc: Christer Holmberg , Simon Perreault , RTCWeb IETF , mmusic WG To: Roman Shpount References: <874l9ousuk.fsf@hobgoblin.ariadne.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 15:03:53 -0000 --Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If that update was to be made, this goes against the text in = draft-ietf-rtcweb-mdns-ice-candidates-02 which says: An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others. The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. But there=E2=80=99s a bigger problem here, which is how to cope with an = FQDN is not resolvable. So the intention, as I understand it, is that = when these host candidates leave the mDNS domain and are thus not = resolvable, they will be treated as peer reflexive candidates. But at that point there is no address family information available, so = how does an ICE agent know to do pairing with these candidates, which = requires the address family to be known? Regards, Alan > On 1 Feb 2019, at 21:06, Roman Shpount wrote: >=20 > In this case section 4.1 of ice-sip-sdp should be updated to allow = FQDN in connection-address and, perhaps specify that FWDN which return = multiple results should be ignored. >=20 > Would this work for everyone? >=20 > Regards, > _____________ > Roman Shpount >=20 >=20 > On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg = > = wrote: > I have no problem with allowing FQDNs - as long as they result in a = SINGLE address:port. >=20 > If we want to define ICE usage of FDNSs resulting in MULTIPLE = addresses:ports, I really think that should be a separate document - it = should NOT be added as a last minute thing to draft-ice-sip-sdp. >=20 > ...and, yes, perhaps such work would also affect 8445. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > From: rtcweb > on behalf of Roman Shpount = > > Sent: Friday, February 1, 2019 10:22 PM > To: Justin Uberti > Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG > Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when = FQDN is used for the default candidate? > =20 > On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti > wrote: > This has all been discussed at length in rtcweb and I don't think any = significant changes are needed, although I tend to think that we should = restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only = thing not in alignment at this point in time. >=20 > I agree that FQDN should be put back into connection-address = definition, but the portion which talks about handling it is completely = broken.. >=20 > Quoting 5245 : > : 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 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=3Dcandidate = 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. >=20 > I think it was discussed in quite a detail why using a random DNS = resolution result is not going to work here.. >=20 > The only options we have here are: >=20 > a. Fix FQDN connection address handling. Probably the most logical way = of dealing with this would be to specify that candidate with FQDN should = be converted as a result of DNS resolution into multiple candidates, = with each candidate corresponding to A or AAAA record in DNS query = result. We will also need to specify how FQDN candidate gets applied to = c=3D line address. Something that says IN IP4 FQDN, if any A records = exist for this DNS name and IN IP6 FQDN if only AAAA records exist. Once = candidate is nominated, address family in c=3D line should match address = family used for communications. This will definitely require a lot more = work and discussion. >=20 > b. Specify that FQDN connection addresses should be ignored until = their handling is defined in a future specification. This seems easy and = only requires a sentence or two to fix. >=20 > Regards, > _____________ > Roman Shpount > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = that update was to be made, this goes against the text = in draft-ietf-rtcweb-mdns-ice-candidates-02 which says:

   An ICE = agent that supports mDNS candidates MUST support the situation
   where the hostname resolution results in more = than one IP address.
   In this case, the ICE = agent MUST take exactly one of the resolved IP
  =  addresses and ignore the others.  The ICE agent SHOULD, if = available,
   use the first IPv6 address = resolved, otherwise the first IPv4
  =  address.

But there=E2=80=99s a bigger problem here, which = is how to cope with an FQDN is not resolvable. So the intention, as I = understand it, is that when these host candidates leave the mDNS domain = and are thus not resolvable, they will be treated as peer reflexive = candidates.

But at that point there = is no address family information available, so how does an ICE agent = know to do pairing with these candidates, which requires the address = family to be known?

Regards,
Alan

On 1 Feb = 2019, at 21:06, Roman Shpount <roman@telurix.com> wrote:

In this case section 4.1 of = ice-sip-sdp should be updated to allow FQDN in connection-address and, = perhaps specify that FWDN which return multiple results should be = ignored.

Would this work for everyone?

Regards,
_____________
Roman = Shpount


On Fri, Feb = 1, 2019 at 4:02 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
I have no = problem with allowing FQDNs - as long as they result in a SINGLE = address:port.

If = we want to define ICE usage of FDNSs resulting in MULTIPLE = addresses:ports, I really think that should be a separate document - it = should NOT be added as a last minute thing to = draft-ice-sip-sdp.

...and, yes, perhaps such work would also affect = 8445.

Regards,

Christer





From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Roman Shpount = <roman@telurix.com>
Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; = mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D = line address when FQDN is used for the default candidate?
 
On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <juberti@google.com> wrote:
This has all been discussed at length in = rtcweb and I don't think any significant changes are needed, although I = tend to think that we should restore the removed FQDN text from = mmusic-ice-sip-sdp, which is the only thing not in alignment at this point in time.

I agree that FQDN should be put back into = connection-address definition, but  the portion which talks about = handling it is completely broken..

Quoting 5245:
   =
<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 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=3Dcandidate 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.

I think it was discussed in quite a detail why using a random DNS = resolution result is not going to work here..

The only options we have here are:

a. Fix FQDN connection address handling. Probably the = most logical way of dealing with this would be to specify that candidate = with FQDN should be converted as a result of DNS resolution into = multiple candidates, with each candidate corresponding to A or AAAA record in DNS query result. We will also need to specify = how FQDN candidate gets applied to c=3D line address. Something that = says IN IP4 FQDN, if any A records exist for this DNS name and IN IP6 = FQDN if only AAAA records exist. Once candidate is nominated, address family in c=3D line should match address family used = for communications. This will definitely require a lot more work and = discussion.

b. Specify that FQDN connection addresses should be = ignored until their handling is defined in a future specification. This = seems easy and only requires a sentence or two to fix.

Regards,
_____________
Roman Shpount
_______________________________________________
mmusic = mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

= --Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114--