Subject: [MMUSIC] FQDN Support Final Vote

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 21 May 2019 08:26:33 -0700

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 May 2019 10:59:08 -0700

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 <[email-masked]>
wrote:

>       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.
>
>
> <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
>
> <connection-address>: :: is taken from RFC 4566 <<RFC4566>>.. It is the IP
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 May 2019 16:43:22 -0400

I wanted to explain what I was trying to achieve with the proposed language:

1. State that specification of how FQDN are resolved or how offer with FQDN
is generated, including interop with FQDN in candidate attributes generated
by agents implementing RFC 5245 will be provided in a future draft.

2. State that agents that implement ice-sip-sdp do not generate offers with
FQDN in connection address unless they implement some future specification
that describes how this is done.

3. State that it is legal to ignore ICE candidates with FQDN connection
address and that these candidates MUST be ignored by agents that implement
ice-sip-sdp unless this agent implements some future draft which describes
how FQDN resolution is done.

4. Clarify ICE support validation procedures when processing session
descriptions with FQDN in candidate connection address. Specifically, if
agent implementing ice-sip-sdp receives a session description where
candidate with FQDN connection address is the default candidate, address in
c= line must be the literal FQDN value used connection address of the
default candidate. If address in c= line is an IP address which is result
of the FQDN resolution of candidate connection address, or FQDN which
resolves to the same IP address as FQDN in the candidate, or anything else
except the literal FQDN value used in the default candidate connection
address, then this m= line must be treated as ICE mismatch. On the other
hand, difference in address family and type between c= line and FQDN
resolution result (regardless of what procedure is used to resolve FQDN),
must not be considered a mismatch.

I do not like the current language in ice-sip-sdp, since it does provide a
description on how connection addresses with FQDN are generated and
handled, but does it in a way that is known to cause problems. Also,
current language does not allow for FQDN to be ignored or specify how ICE
mismatch conditions are handled when FQDN connection address is used.

The language that I have provided can certainly be improved, but I would
really like the above stated items to be covered in the current draft to
allow for future extension and FQDN support.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2019 21:09:19 +0000

Hi,

>4. Clarify ICE support validation procedures when processing session descriptions with FQDN in candidate connection address. Specifically, if agent implementing ice-sip-sdp receives a session >description where candidate with FQDN connection address is the default candidate, address in c= line must be the literal FQDN value used connection address of the default candidate. If >address in c= line is an IP address which is result of the FQDN resolution of candidate connection address, or FQDN which resolves to the same IP address as FQDN in the candidate, or anything >else except the literal FQDN value used in the default candidate connection address, then this m= line must be treated as ICE mismatch. On the other hand, difference in address family and type >between c= line and FQDN resolution result (regardless of what procedure is used to resolve FQDN), must not be considered a mismatch.

It is very difficult for me to parse what you are trying to say in bullet 4.

If an agent receives SDP with an IP address in the c= line, how does it know whether it is a “result of the FQDN resolution of the candidate connection address”? Does that agent have to do a DNS lookup after all, to see whether the result matches the IP address in the c= line?

> I do not like the current language in ice-sip-sdp, since it does provide a description on how connection addresses with FQDN are generated and handled, but does it in a way that is known to
> cause problems. Also, current language does not allow for FQDN to be ignored or specify how ICE mismatch conditions are handled when FQDN connection address is used.

I don’t think anyone disagree with changing the current text?

Regards,

Christer

On Tue, May 21, 2019 at 11:26 AM Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> 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

ice-sip-sdp current version

      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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 May 2019 17:19:10 -0400

On Tue, May 21, 2019 at 5:09 PM Christer Holmberg <
[email-masked]> wrote:

> agent implementing ice-sip-sdp receives a session >description where
> default candidate. If >address in c= line is an IP address which is result
> resolves to the same IP address as FQDN in the candidate, or anything >else
> hand, difference in address family and type >between c= line and FQDN
> If an agent receives SDP with an IP address in the c= line, how does it
> know whether it is a “result of the FQDN resolution of the candidate
> connection address”? Does that agent have to do a DNS lookup after all, to
> see whether the result matches the IP address in the c= line?
>

I am talking about Verifying ICE Support Procedures (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-27#section-3.2.5)
when session description is received with FQDN in default candidate. What I
am saying is that when validating ICE Support, connection address in c=
line MUST be literal FQDN from default candidate. Not its IP address or
some other resolution result, but actual FQDN. Also, in case FQDN is used
in default candidate, ice mismatch should not be caused by any values of
address family and type in c= line. This way client does not need to do
FQDN resolution when validating ICE support. For instance, Suhas suggests
that IP address and family should be used in c= line when FQDN is used in
default candidate, but, in this case, ICE support cannot be validated
without resolving FQDN and even this can produce accidental ICE mismatch
based on resolution result.

> I do not like the current language in ice-sip-sdp, since it does provide
> a description on how connection addresses with FQDN are generated and
> handled, but does it in a way that is known to
>
> > cause problems. Also, current language does not allow for FQDN to be
> ignored or specify how ICE mismatch conditions are handled when FQDN
> connection address is used.
>
>
>

Suhas is arguing for existing text.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2019 21:41:57 +0000

Hi,

>>4. Clarify ICE support validation procedures when processing session descriptions with FQDN in candidate connection address. Specifically, if agent implementing ice-sip-sdp receives a session >>description where candidate with FQDN connection address is the default candidate, address in c= line must be the literal FQDN value used connection address of the default candidate. If >>address in c= line is an IP address which is result of the FQDN resolution of candidate connection address, or FQDN which resolves to the same IP address as FQDN in the candidate, or anything >>else except the literal FQDN value used in the default candidate connection address, then this m= line must be treated as ICE mismatch. On the other hand, difference in address family and type >>between c= line and FQDN resolution result (regardless of what procedure is used to resolve FQDN), must not be considered a mismatch.
>> 
>> If an agent receives SDP with an IP address in the c= line, how does it know whether it is a “result of the FQDN resolution of the candidate connection address”? 
>> Does that agent have to do a DNS lookup after all, to see whether the result matches the IP address in the c= line?
> 
> I am talking about Verifying ICE Support Procedures (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-27#section-3.2.5) when session description is received 
> with FQDN in default candidate.

First, not related to FQDN, I don't think the text in section 3.2.5 is valid anymore - or at least it needs to be modified. It says that if the SDP does not contain a candidate for each component it shall continue with normal RFC 3264 procedures.

But, I understand that we will now explicitly say that an agent receiving an SDP without candidates is valid, but the agent will still continue with the ICE procedures.

> What I am saying is that when validating ICE Support, connection address in c= line MUST be literal FQDN from default candidate. Not its IP address or some other 
> resolution result, but actual FQDN. Also, in case FQDN is used in default candidate, ice mismatch should not be caused by any values of address family and type 
> in c= line. This way client does not need to do FQDN resolution when validating ICE support. For instance, Suhas suggests that IP address and family should be 
> used in c= line when FQDN is used in default candidate, but, in this case, ICE support cannot be validated without resolving FQDN and even this can produce 
> accidental ICE mismatch based on resolution result.

Isn't the agent going to discard the FQDN candidate - no matter if it is the default candidate or not? The FQDN problems apply to such candidates too.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 May 2019 18:12:43 -0400

On Tue, May 21, 2019 at 5:42 PM Christer Holmberg <
[email-masked]> wrote:

> agent implementing ice-sip-sdp receives a session >>description where
> default candidate. If >>address in c= line is an IP address which is result
> resolves to the same IP address as FQDN in the candidate, or anything
> >>else except the literal FQDN value used in the default candidate
> connection address, then this m= line must be treated as ICE mismatch. On
> the other hand, difference in address family and type >>between c= line and
> FQDN resolution result (regardless of what procedure is used to resolve
> FQDN), must not be considered a mismatch.
> >>
> connection address”?
> >> Does that agent have to do a DNS lookup after all, to see whether the
> result matches the IP address in the c= line?
> >
> when session description is received
> First, not related to FQDN, I don't think the text in section 3.2.5 is
> valid anymore - or at least it needs to be modified. It says that if the
> SDP does not contain a candidate for each component it shall continue with
> normal RFC 3264 procedures.
>
> But, I understand that we will now explicitly say that an agent receiving
> an SDP without candidates is valid, but the agent will still continue with
> the ICE procedures.
>

To be clear, 3.2.5  adds an exception when default address
is "0.0.0.0"/"::" and port is "9", but this can be made clearer.

There are a few more problems with the language in 3.2.5, such as stating
that a=ice-mismatch is a session level attribute and applies to the entire
ICE session, not just a single m= line.

I have suggested some edits for this section but more might be needed.

> What I am saying is that when validating ICE Support, connection address
> in c= line MUST be literal FQDN from default candidate. Not its IP address
> or some other
> > resolution result, but actual FQDN. Also, in case FQDN is used in
> default candidate, ice mismatch should not be caused by any values of
> address family and type
> > in c= line. This way client does not need to do FQDN resolution when
> validating ICE support. For instance, Suhas suggests that IP address and
> family should be
> > used in c= line when FQDN is used in default candidate, but, in this
> case, ICE support cannot be validated without resolving FQDN and even this
> can produce
> Isn't the agent going to discard the FQDN candidate - no matter if it is
> the default candidate or not? The FQDN problems apply to such candidates
> too.
>
>
Agent receiving the session description can discard ICE candidates with
FQDN. Agent that generated the session description could have used FQDN for
the default candidate in the c= line. ICE candidate is discarded when
generating a candidate list for ICE processing, but it is still used for
ICE support verification, which occurs earlier. This is the same as IPv6
address which can be discarded by an agent on IPv4 only network, but would
still correctly validate ICE support if this IPv6 address were used in c=
line.

Regards,
_____________
Roman Shpount

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 24 May 2019 09:04:41 -0400

I support that as well.

Christer: I'm not clear on what your vote is right now.

Thanks

-- Flemming (as individual)

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 <[email-masked] 
> <mailto:[email-masked]>> 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 *
>     <https://tools.ietf.org/html/rfc4566>[RFC4566
>     **
>     <connection-address>:is taken from RFC 4566 [RFC4566].It is the IP
>     address of the candidate.When parsing this field, an agent can
>     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.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
>
>     <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.*
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 May 2019 13:08:45 +0000

Hi,

>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.
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 <[email-masked]<mailto:[email-masked]>> 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

      addresses.

Roman-Christer Version
candidates with FQDN or IP address versions that are not supported or recognized..  The procedures for handling FQDN candidates, and for agents

mmusic mailing list

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 24 May 2019 09:23:43 -0400

On 5/24/19 9:08 AM, Christer Holmberg wrote:
> 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

>     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
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi All
>
>         support in ice-sip-sdp. Let's agree on one and go with it
>         (even it doesn't make us entirely happy)..
>
>         *RFC5245 Version *
>
>               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.
>
>         <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
>
>         <connection-address>: :: is taken from RFC 4566 <<RFC4566>>..
>         It is the IP address of the candidate, allowing for IPv4
>         addresses, IPv6 addresses,
>
>         of a colon in its value - the presence of a colon indicates
>         IPv6. *An agent processing remote candidates MUST ignore
>         candidate lines that include*
>
>         *to indicate support of such procedures, need to be specified
>         in an extension specification.* If candidate with FQDN
>         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.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 May 2019 15:22:26 +0000

Hi,

As far as not allowing FQDN candidates is concerned, I think we have text. I have not seen any objection.

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?

Regards,

Christer
________________________________
From: Flemming Andreasen <[email-masked]>
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

Hi,

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

Hi All

RFC5245 Version

      addresses.

Roman-Christer Version

mmusic mailing list

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 24 May 2019 12:03:48 -0400

> 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 <[email-masked]>
> *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
>
>
>>         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.
>>
>>         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
>>         by fixing the source address to be one from the candidate
>>         pair to be matched against destination addresses
>>
>>         field, an agent can differentiate  an IPv4 address and an
>>         IPv6 address by presence
>>
>>         *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.*
>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 May 2019 19:33:43 +0000

Hi,

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

> 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:[email-masked]
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 

Thanks 

-- Flemming 

Regards,
Christer

On Tue, May 21, 2019 at 8:26 AM Suhas Nandakumar <mailto:[email-masked]> wrote:
Hi All

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

Roman-Christer Version 

mailto:[email-masked]

mailto:[email-masked]

mailto:[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Fri, 24 May 2019 17:47:38 -0400

On Fri, May 24, 2019 at 3:33 PM Christer Holmberg <
[email-masked]> wrote:

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

I am fine with this change.

> “verification of ICE support”. If that is needed, could it be in a separate
> section and/or paragraph?
> "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
> 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?
>
>
I like this. let's just add an appropriate clause to the verifying ICE
support procedures.

Current language in section 3.2.5 specifies:

If this condition is not met, the agents MUST process the SDP based on
normal [RFC3264] procedures, without using any of the ICE mechanisms
described in the remainder of this specification with the few exceptions
noted below:

1.  The presence of certain application layer gateways MAY modify the
transport address information as described in Section 8.2.2.  The behavior
of the responding agent in such a situation is implementation defined.
Informally, the responding agent MAY consider the mismatched transport
address information as a plausible new candidate learnt from the peer and
continue its ICE processing with that transport address included.
Alternatively, the responding agent MAY include an "a=ice-mismatch"
attribute in its answer and MAY also omit a=candidate attributes for such
data streams.

2.  The transport address from the peer for the default destination
correspond to IP address values "0.0.0.0"/"::" and port value of "9".  This
MUST not be considered as a ICE failure by the peer agent and the ICE
processing MUST continue as usual.

I would suggest adding:

3.  The transport address from the peer for the default destination is
an FQDN.  Regardless of the procedures used to resolve FQDN or the
resolution result, this MUST not be considered as a ICE failure by the peer
agent and the ICE processing MUST continue as usual.

If this is added the second part that Christer found confusing can be
removed.

Regards,
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 25 May 2019 04:12:42 +0530

Thanks Roman .. just to ensure we are all on same page . Would you be ok to
create a new PR for FdN support from yours and Christers proposal  . We
will have one place to approve it and get it merged

Please let me know

Thanks
Suhas

On Sat, May 25, 2019 at 3:17 AM Roman Shpount <[email-masked]> wrote:

>> 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
>> "<connection-address>: :: is taken from RFC 4566 <<RFC4566>>. It is the
>> IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses,

---

From: Roman Shpount <[email-masked]>
Date: Fri, 24 May 2019 19:28:47 -0400

Suhas,

I have created a pull request on top of the mismatch branch:
https://github.com/suhasHere/ice-sip-sdp/pull/3

New language in ICE Verification procedures is:

The transport address from the peer for the default destination is an
FQDN.  Regardless of the procedures used to resolve FQDN or the
resolution result, this MUST not be considered as a ICE failure by the peer
agent and the ICE processing MUST continue as usual.

New language for connection address:

<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
generating local candidates MUST not use FQDN addresses. 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
generation and handling FQDN candidates, as well as, how agents indicate
support of such procedures, need to
be specified in an extension specification.

I have kept Christer's edits and, since we provide no guidance on how to do
this, I added extra language that agents must not use FQDN when generating
local candidates.

Regards,
_____________
Roman Shpount

On Fri, May 24, 2019 at 6:42 PM Suhas Nandakumar <[email-masked]>
wrote:

> Thanks Roman .. just to ensure we are all on same page . Would you be ok
> to create a new PR for FdN support from yours and Christers proposal  . We
>>> 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