Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?

[Justin Uberti <[e-mail]>]

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 <
[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> on behalf of Roman Shpount <
> [e-mail]>
> *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 <[e-mail]> 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 <https://tools.ietf.org/html/rfc5245#section-15.1>:
>
>    <connection-address>:  is taken from RFC 4566 <https://tools.ietf.org/html/rfc4566> [RFC4566 <https://tools.ietf.org/html/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
>
>