Re: [MMUSIC] FQDN Support Final Vote

[Flemming Andreasen <[e-mail]>]

On 5/24/19 11:22 AM, Christer Holmberg wrote:
> Hi,
>
> As far as not allowing FQDN candidates is concerned, I think we have 
> text. I have not seen any objection.
I'm not clear on exactly what text you are agreeing to here.
>
> Now, in addition to that, Roman wants to cover FQDNs in c= lines. for 
> “verification of ICE support”. If that is needed, could it be in a 
> separate section and/or paragraph?
>
Can you please provide a concrete text suggestion that satisfies your 
concerns.

Thanks

-- Flemming
> Regards,
>
> Christer
> ------------------------------------------------------------------------
> *From:* Flemming Andreasen <[e-mail]>
> *Sent:* Friday, May 24, 2019 4:23:43 PM
> *To:* Christer Holmberg; Bernard Aboba; Suhas Nandakumar
> *Cc:* mmusic WG
> *Subject:* Re: [MMUSIC] FQDN Support Final Vote
>
>
> On 5/24/19 9:08 AM, Christer Holmberg wrote:
>>
>> Hi,
>>
>> >I support that as well.
>> >
>> >Christer: I'm not clear on what your vote is right now.
>>
>> My vote is to **not** support FQDN candidates, and add whatever text 
>> needed to explicitly indicate that.
>>
> If none of the 4 proposals work for you, can you please provide a 
> concrete text suggestion we can take a look at.
>
> Thanks
>
> -- Flemming
>
>> Regards,
>>
>> Christer
>>
>> On 5/21/19 1:59 PM, Bernard Aboba wrote:
>>
>>     Personally, I like the suggested text from Christer and Roman
>>     because it explicitly states that if FQDNs are not supported then
>>     the candidates must be ignored.
>>
>>     On Tue, May 21, 2019 at 8:26 AM Suhas Nandakumar
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         Hi All
>>
>>           Below i have included 4 flavors of suggested text for FQDN
>>         support in ice-sip-sdp.  Let's agree on one and go with it
>>         (even it doesn't make us entirely happy)..
>>
>>         *RFC5245 Version *
>>
>>         "<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.
>>
>>         *ice-sip-sdp pre-22 version1*
>>
>>         **
>>
>>         <connection-address>:is taken from RFC 4566 [RFC4566].It is
>>         the IP address of the candidate.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 withIP 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 lookedup 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 record.The rules from section 6 of [RFC6724] is followed
>>         by fixing the source address to be one from the candidate
>>         pair to be matched against destination addresses
>>
>>         reported by FQDN, in cases where the DNS query returns more
>>         than one IP address.
>>
>>         *ice-sip-sdp current version*
>>
>>         <connection-address>:  is taken from RFC 4566 [RFC4566].  It
>>         is the
>>
>>               IP address of the candidate.  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 record.  If a FQDN returns
>>         multiple IP
>>
>>               addresses an agent MUST only use one of them throughout the
>>
>>               duration of the ICE session.  Since an agent does not
>>         know whether
>>
>>               the peer listens to the chosen IP address and port, it is
>>
>>               RECOMMENDED to not use FQDNs that will resolve into
>>         multiple IP
>>
>>               addresses.
>>
>>         *Roman-Christer Version *
>>
>>         <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.
>>
>>         *My vote is on current version since it is backward
>>         compatible with a warning that using FQDN is not recommended
>>         since it MAY lead to failure.*
>>
>>         _______________________________________________
>>         mmusic mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>>     _______________________________________________
>>
>>     mmusic mailing list
>>
>>     [e-mail]  <mailto:[e-mail]>
>>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]  <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mmusic
>