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 7AAA6130F6D for ; Fri, 1 Feb 2019 15:28: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=unavailable 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 7dBS-wMyDHyS for ; Fri, 1 Feb 2019 15:28:12 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 4C0CB130DFA for ; Fri, 1 Feb 2019 15:28:12 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id t24so7196264ioi.0 for ; Fri, 01 Feb 2019 15:28:12 -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=1ot9NtzC2DaxpHhVI//RiX2SQDQ2wZDVa1JI2nBQD2Q=; b=SRFRMx/bEi5BZWQKo3OW+1XPD1XiPPv16Mzlt1+WR+iFsOCMwgKVxvt8kdli4eHEkB lVlUEs/S9RUgxOS7rXDtDxSjqM5OJ+6VuIw8PXdAXI8erDNlTwlBLQRDgM+kUDdLMT+k OsjYNeIFaAdkjsW7SiQhpIMKBVWGNjvewCwN02f2gNWRY6wyjEQ0+YaLGkzY47g+ypGt HbSxUttex+n2DFFLxf/gnsp7z9mE1hfd9HLcMw5wMF/LJukjmGMOkCkbZaQFRZyCMxTP MbIJKx+YZyPMpqfNJiWZ0YT8cbF2TR1Y/Vu9ym7rE75ZZblTtlG8QNgyLh+KMcl4DxWn tWlQ== 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=1ot9NtzC2DaxpHhVI//RiX2SQDQ2wZDVa1JI2nBQD2Q=; b=nHtBsU8Wq+rykZR9Y/0qJqrLzsYxQ04DO5VJcU7kvUWoPi9txwXS55DainKv0yaSYc djhE2vTrYKQM1/krwhCOydIaYrdpS2vOdYZqm8ROnYqSkdHBrG159hUox3Y59gRrJnY+ BrzeyS2CYp07xZvnL2wWSKMeLW7FSL0cUqqSgYhP/2b0yA2kN1Gvojyhxjjvrte/DDTi yDnS9mRmRJlpElFyc3EXiKYpohIcnzdjhku92dat5ZefdzPCD//0L8dNpGTOWxI47Q/7 Ut77NR5M4ajsaXofN9i3tlt9XYJNGTEiAMfKls1u24ylLEt1UiugZNswbnD49Ta4lUX5 0L2w== X-Gm-Message-State: AHQUAuaZAV243vunkMsoyj0TWsKRD9asAUpr9WZ7RsiWn3yaGl0djt0n p5mGxf8a/TjN+8tvXM1G9BTb/B7AbpT0pyRWZTYIYQ== X-Google-Smtp-Source: AHgI3IYdJUF4HlMD0PRr2IV8iHBKMUWmU/jMa5eKJ6z6FtgTZgD9YEslUDyyw535bAcHFF8/cFccg3FXp7cbiXkm8BE= X-Received: by 2002:a5e:920d:: with SMTP id y13mr22265000iop.95.1549063691156; Fri, 01 Feb 2019 15:28:11 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Justin Uberti Date: Fri, 1 Feb 2019 15:27:56 -0800 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Simon Perreault , "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000000c703c0580dd7ff3" 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: Fri, 01 Feb 2019 23:28:16 -0000 --0000000000000c703c0580dd7ff3 Content-Type: text/plain; charset="UTF-8" That works for me as well - it then becomes a clarification of 5245, rather than a removal of functionality. On Fri, Feb 1, 2019 at 1:17 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > > 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. > > I suggest MUST be ignored, perhaps with a note saying that a future > specification will have to define how to use FQDNs that return multiple > results. > > > Would this work for everyone? > > It would work for me. > > Regards, > > Christer > > > > 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 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= line address when FQDN > is used for the default candidate? > > 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. > > > 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 : > > : 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=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. > > > 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= 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= 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 > > --0000000000000c703c0580dd7ff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That works for me as well - it then becomes a clarifi= cation of 5245, rather than a removal of functionality.

On Fri, Feb 1, 2019 = at 1:17 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:


Hi,
=C2=A0
> In this case section 4.1 of ice-sip-sdp should be upd= ated to allow FQDN in=C2=A0
> connection-address and, perhaps specify that FWDN whi= ch return multiple=C2=A0
> results should be ignored.

I suggest MUST be ignored, perhaps with a note saying that= a future specification will have to define how to use FQDNs that return mu= ltiple results.

> Would this work for everyone?

It would work for me.

Regards,

Christer



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 SINGL= E address:port.


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


...and, yes, perhaps such wor= k would also affect 8445.


Regards,


Christer






From: rtcweb <rtcweb-bounces@ietf.o= rg> 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?
=C2=A0
On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <= ;juber= ti@google.com> wrote:
This has all been discussed at length in rtcweb and I don&= #39;t think any significant changes are needed, although I tend to think th= at we should restore the removed FQDN text from mmusic-ice-sip-sdp, which i= s the only thing not in alignment at this point in time.

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

Quoting=C2=A05245:
   <connection-address>:  is taken from RFC 4566 [<=
a title=3D""SDP: Session Description Protocol"" class=3D"gmail-m_=
4281477119354329881x_gmail-m_-7925862921453132447OWAAutoLink gmail-m_428147=
7119354329881OWAAutoLink" id=3D"gmail-m_4281477119354329881LPlnk550807" hre=
f=3D"https://tools.ietf.org/html/rfc4566" target=3D"_blank">RFC4566].  =
It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When par=
sing
      this field, an agent can differentiate an IPv4 address and an IPv6

      address by presence of a colon in its value - the presence o=
f 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 resolutio= n 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 b= e converted as a result of DNS resolution into multiple candidates, with ea= ch 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 FQD= N, if any A records exist for this DNS name and IN IP6 FQDN if only AAAA re= cords exist. Once candidate is nominated, address family in c=3D line should match address family used for communica= tions. This will definitely require a lot more work and discussion.

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

Regards,
_____________
Roman Shpount
--0000000000000c703c0580dd7ff3--