Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

On Tue, May 21, 2019 at 7:36 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> Roman suggested text yesterday, and with my change suggestion it would
> look like:
>
>
>
> <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 processing remote candidates MUST ignore candidate lines that include
> *
>
> *candidates with FQDN or IP address versions that are not supported or
> recognized.  The procedures for handling FQDN candidates, and for agents *
>
> *to indicate support of such procedures, need to be specified in an
> extension specification.* If candidate with FQDN <connection-address> is
> the
>
> default destination/candidate, the "c=" address type MUST be set the IP
> address family for the FQDN DNS resolution result and the "c=" connection
>
> address MUST be set to FQDN. Differences in the "c=" line address family
> and type with FQDN resolution result MUST not cause ICE support
> verification failure.
>
> The text in bold covers the
> must-ignore-FQDN-and-will-be-specified-in-an-extension-specification part.
>

[Suhas] Doesn't must ignore is a new behavior we are adding . I wonder what
does this mean to legacy issues that Bernard referred to ?

>
>
> Now, I have some difficulties to understand the last sentence. It seems to
> indicate that some FQDN DNS resolution is performed, and that the IP family
> is set according to the result. But, what if the result contains both IPv6
> and IPv4?
>
>
>
> Also, I assume that the procedures in the last sentence is related to the
> provider of the candidates. If so, it needs to be more clear.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *mmusic <mmusic-bounces@ietf.org> on behalf of Flemming Andreasen <
> fandreas@cisco.com>
> *Date: *Tuesday, 21 May 2019 at 14.40
> *To: *Suhas Nandakumar <suhasietf@gmail.com>, Roman Shpount <
> roman@telurix.com>
> *Cc: *Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org"
> <mmusic@ietf.org>
> *Subject: *Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in
> ice-sip-sdp
>
>
>
>
>
> On 5/21/19 1:01 AM, Suhas Nandakumar wrote:
>
>
>
>
>
> On Mon, May 20, 2019 at 8:19 PM Roman Shpount <roman@telurix.com> wrote:
>
> There was a bit of discussion earlier about this and the understanding was
> that RFC 8445 does not deal with FQDN or DNS resolution. RFC 8445 gets a
> list of candidates with IP Addresses. FQDN resolution as well as the format
> in which candidates are encoded would be a part of some other draft such
> ice-sip-sdp or an extension.
>
>
>
> [suhas] .. I don’t understand why FQDN resolution should be scoped in
> ice-sip-sdp whose main purposes is offer / answer negotiation and yes
> encoding provided candidates. I agree with Bernard and vote to move fqdn
> resolution outside ice-sip-sdp into a new draft
>
>
>
> I'm leaning towards that as well. Trying to rush an FQDN solution into
> ice-sip-sdp does not seem like a good idea, and we need to move this draft
> forward.
>
> Thanks
>
> -- Flemming (as individual)
>
>
>
>
>
>
>
> Also, using ice2 option does not help much since offer with FQDN in
> connection address would have to be generated before agent knows if remote
> party supports ice2. Bottom line is if remote party fails to parse FQDN
> there is nothing that can be done to generate an offer that will be
> compatible (except for putting FQDN in candidate extension). If FQDN is
> ignored or handled according to RFC 5245 procedure then it is safe to
> insert FQDN in contact address since either behavior would no worse then
> candidate pair connectivity check failing.
>
>
>
> Roman Shpount
>
>
>
> On Mon, May 20, 2019, 22:51 Bernard Aboba <bernard.aboba@gmail.com> wrote:
>
> I would recommend updating RFC 8445 to require that implementations that
> do not support FQDNs ignore them.  That way we can assume that
> implementations including an 'ice2' option will ignore FQDNs if they are
> unsupported.  Then the MDNS draft can cite RFC 8445.
>
>
>
> On Mon, May 20, 2019 at 7:34 PM Roman Shpount <roman@telurix.com> wrote:
>
> What do you suggest?
>
>
>
> Most of the legacy implementations would fail to parse FQDN in the
> connection address.
>
> Roman Shpount
>
>
>
> On Mon, May 20, 2019, 21:55 Bernard Aboba <bernard.aboba@gmail.com> wrote:
>
> "If FQDN is allowed but ignored, this will allow "legacy" implementations
> to interop with ICE implementation which support mDNS or generic FQDN. How
> FQDN are resolved and how ICE agents specify to each other the these
> procedures are supported can and should be part of mDNS or generic FQND
> support draft. If I am missing something and something else is required,
> mDNS authors should comment."
>
>
>
> [BA] Unfortunately, RFC 5245 did not mandate that FQDNs be ignored by
> implementations that did not choose to support them.  All it says is this:
>
>
>
> <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.
>
>
>
> So while there are good reasons why modern ICE implementations should
> support FQDNs (e.g. for NAT64 support), "legacy" implementations are by
> definition not modern.  Given that RFC 5245-compliant implementations were
> not obligated to either send FQDNs or to correctly handle them if they were
> not supported, we need to look at what legacy implementations do, not what
> we would prefer that they do.
>
>
>
> Since RFC 5245 did not mandate either FQDN support or even resilient
> behavior in non-supporting implementations, problems such as the one below
> (or much worse) are to be expected:
>
> https://bugs.chromium.org/p/webrtc/issues/detail?id=4165
>
>
>
> So if were are attempting to interoperate with the vast body of existing
> implementations, we should assume that we have to contend with legacy
> implementations have been baked into equipment, or forked to create mobile
> applications that have not been resync'd in years.  Note that this is a
> very different circumstance from browser-browser interop where "evergreen"
> is rapidly becoming the rule among WebRTC-capable browsers.
>
>
>
> On Mon, May 20, 2019 at 4:14 PM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> >If FQDN is allowed but ignored, this will allow "legacy" implementations
> to interop with ICE implementation which support mDNS or generic FQDN.
> >How FQDN are resolved and how ICE agents specify to each other the these
> procedures are supported can and should be part of mDNS or generic
> >FQND support draft. If I am missing something and something else is
> required, mDNS authors should comment.
>
> I don’t think you are missing anything.
>
> So far this is my proposal for ice-sip-sdp connection address definition
> which should implement option 2:
>
> ><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 FQDN or IP address
> versions that are not supported or recognized.  Handling of FQDN addresses
> in candidate can be defined in the future specification. If candidate >with
> FQDN <connection-address> is the default destination/candidate, the the
> "c=" address type MUST be set the IP address family for the FQDN DNS
> resolution result and the "c=" connection >address MUST be set to FQDN.
> Differences in the "c=" line address family and type with FQDN resolution
> result MUST not cause ICE support verification failure.
>
> Minor change suggestion:
>
> "The procedures for handling FQDN addresses, and for agents to indicate
> support of such procedures, need to be specified in an extension
> specification."
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>