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

[Flemming Andreasen <[e-mail]>]

On 5/21/19 1:01 AM, Suhas Nandakumar wrote:
>
>
> On Mon, May 20, 2019 at 8:19 PM Roman Shpount <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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
>         <[e-mail] <mailto:[e-mail]>> 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
>             <[e-mail] <mailto:[e-mail]>>
>             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 fromRFC 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
>                 <[e-mail]
>                 <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>