Re: [MMUSIC] FQDN Support Final Vote

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. 

I am fine (and I have seen nobody object) to the following part of Roman's suggested text (with some modifications by myself), which is about discarding FQDN candidates:

"<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."

>> 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. 

The second part of Roman's text covered that:

"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."

I had some problems to parse the text, but that is probably only editorial. But, I *think* Suhas raised some technical issues with it.

One way could be to simply say that, if the c= line contains a FQDN, the agent simply does not look for a matching candidate. Because, if the agent is anyway going to discard FQDN candidates, why does it matter whether the c= line FQDN has a matching FQDN candidate?

Regards,

Christer

From: Flemming Andreasen mailto:fandreas@cisco.com
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 <mailto:suhasietf@gmail.com> 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 https://tools.ietf.org/html/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 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.  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
mailto:mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mailto:mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mailto:mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic