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

From: Flemming Andreasen <[email-masked]>
Date: Sun, 12 May 2019 20:20:20 -0400

Greetings

RFC 8445 does not include support for domain names. There is currently a 
fairly lengthy thread on the MMUSIC list discussing if (and potentially 
how) to deal with domain name support in ice-sip-sdp ("FQDN support in 
ice-sip-sdp). So far only 3 people seem to be interested in this issue, 
they do not agree on the solution, and it has been more than 2 weeks 
since we last saw any traffic on this.

We need to move ice-sip-sdp forward, and since RFC 8445 does not support 
domain names in candidates, and we have yet to find a consensus-based 
solution to adding such support, we propose that we move forward without 
domain name support in ice-sip-sdp (note that it can be added latter as 
an extension in a separate draft).

We are hereby giving people 1 week to object to this (rough) consensus 
call, and if they do, to provide another solution that can garner 
support and consensus on the MMUSIC list.

Thanks

-- Flemmming (with MMUSIC chair on).

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 12 May 2019 22:05:00 -0700

I am willing to leave out FQDN specification but want to bring to notice
the following

Till ice-sip-sdp-22 we had a recommendation about resolving to one IP
Address when multiple match a given FQDN and removed FQDN out from the
later versions.

Here is the original text if it helps (pre-22)

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

Thanks
Suhas

On Sun, May 12, 2019 at 8:40 PM Flemming Andreasen <[email-masked]>
wrote:

> they do not agree on the solution, and it has been more than 2 weeks since
> we last saw any traffic on this.
>
> domain name support in ice-sip-sdp (note that it can be added latter as an
> extension in a separate draft).
>
> call, and if they do, to provide another solution that can garner support
> and consensus on the MMUSIC list.
>
> Thanks
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 May 2019 09:49:31 +0000

Hi,

I would have liked to see the Pull Request before concluding that there is no “agreement”. But, we can obviously not wait forever.

Having said that, related to Suhas’ comment, if we agree to leave FQDN out I think we still need some text.

One option is to put back the text pre-22 text (see below), but I am not sure that solves the issue. Another option is to explicitly say that support and processing of FQDNs are outside the scope of the document, and needs to be covered in a separate specification.

Note, however, that draft-ietf-rtcweb-mdns-ice-candidates assumes that FQDNs are allowed, so in order to progress that draft we either need such separate specification – or draft-ietf-rtcweb-mdns-ice-candidates also needs to cover FQDN support in general.

Regards,

Christer

From: mmusic <[email-masked]> on behalf of Suhas Nandakumar <[email-masked]>
Date: Monday, 13 May 2019 at 8.05
To: Flemming Andreasen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

I am willing to leave out FQDN specification but want to bring to notice the following

Till ice-sip-sdp-22 we had a recommendation about resolving to one IP Address when multiple match a given FQDN and removed FQDN out from the later versions.

      one IP address.

Thanks
Suhas

On Sun, May 12, 2019 at 8:40 PM Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:
Greetings

RFC 8445 does not include support for domain names. There is currently a fairly lengthy thread on the MMUSIC list discussing if (and potentially how) to deal with domain name support in ice-sip-sdp ("FQDN support in ice-sip-sdp). So far only 3 people seem to be interested in this issue, they do not agree on the solution, and it has been more than 2 weeks since we last saw any traffic on this.

We need to move ice-sip-sdp forward, and since RFC 8445 does not support domain names in candidates, and we have yet to find a consensus-based solution to adding such support, we propose that we move forward without domain name support in ice-sip-sdp (note that it can be added latter as an extension in a separate draft).

We are hereby giving people 1 week to object to this (rough) consensus call, and if they do, to provide another solution that can garner support and consensus on the MMUSIC list.

Thanks

-- Flemmming (with MMUSIC chair on).
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 May 2019 17:22:55 -0400

Since there was little feedback on this discussion I would suggest to
specify that FQDN is supported and ignored. I have provided the language in
a separate email.
_____________
Roman Shpount

On Mon, May 13, 2019 at 5:49 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> I would have liked to see the Pull Request before concluding that there is
> no “agreement”. But, we can obviously not wait forever.
>
>
>
> One option is to put back the text pre-22 text (see below), but I am not
> sure that solves the issue. Another option is to explicitly say that
> support and processing of FQDNs are outside the scope of the document, and
> needs to be covered in a separate specification.
>
>
>
> Note, however, that draft-ietf-rtcweb-mdns-ice-candidates assumes that
> FQDNs are allowed, so in order to progress that draft we either need such
> separate specification – or draft-ietf-rtcweb-mdns-ice-candidates also
> needs to cover FQDN support in general.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *mmusic <[email-masked]> on behalf of Suhas Nandakumar <
> [email-masked]>
> *Date: *Monday, 13 May 2019 at 8.05
> *To: *Flemming Andreasen <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in
> ice-sip-sdp
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2019 21:34:40 +0000

What do you mean by ”supported and ignored”? Do you mean “not supported”?

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Monday, 20 May 2019 at 22.23
To: Christer Holmberg <[email-masked]>
Cc: Suhas Nandakumar <[email-masked]>, Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

Since there was little feedback on this discussion I would suggest to specify that FQDN is supported and ignored. I have provided the language in a separate email.
_____________
Roman Shpount

On Mon, May 13, 2019 at 5:49 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>
Date: Monday, 13 May 2019 at 8.05
To: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

      one IP address.

Thanks
Suhas

Thanks

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 May 2019 17:43:31 -0400

What I mean is that FQDN can be included in the ICE candidate
connection-address, but agent MUST ignore such ICE candidate, unless this
agent implements a future specification that defines how FQDN in ICE
candidate connection address is handled.

Please read the proposed text in the other email thread.
_____________
Roman Shpount

On Mon, May 20, 2019 at 5:34 PM Christer Holmberg <
[email-masked]> wrote:

> *From: *Roman Shpount <[email-masked]>
> *Date: *Monday, 20 May 2019 at 22.23
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Suhas Nandakumar <[email-masked]>, Flemming Andreasen <
> [email-masked]>, "[email-masked]" <[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 May 2019 15:07:33 -0700

I am also interested in the issue, but support the consensus call made by
the Chairs (e.g. removal of FQDN support from ice-sip-sdp).

The basic problem we have is that legacy implementations do not support
FQDNs, and RFC 8445 maintained that posture for backwards compatibility
reasons. As a result, we need to pursue FQDN support as a negotiated
extension, not try to wedge it into ice-sip-sdp.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2019 22:21:38 +0000

Hi,

I am fine with removing FQDN, but keep in mind that such “negotiated extension” would then have to be defined in order to progress the mdns-ice draft.

Regards,

Christer

From: Bernard Aboba <[email-masked]>
Date: Monday, 20 May 2019 at 23.07
To: Christer Holmberg <[email-masked]>
Cc: Suhas Nandakumar <[email-masked]>, Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

I am also interested in the issue, but support the consensus call made by the Chairs (e.g. removal of FQDN support from ice-sip-sdp).

The basic problem we have is that legacy implementations do not support FQDNs, and RFC 8445 maintained that posture for backwards compatibility reasons. As a result, we need to pursue FQDN support as a negotiated extension, not try to wedge it into ice-sip-sdp.

On Mon, May 13, 2019 at 2:49 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

      one IP address.

Thanks
Suhas

Thanks

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 May 2019 18:31:45 -0400

Just to be clear, we have 3 options:

1. Define how FQDN is handled
2. Specify that FQDN is allowed in the connection-address of ICE candidate,
but that such candidates MUST be ignored unless some future extension is
negotiated.
3. Prohibit using FQDN in the connection-address

I am in favor of option 2, since it will maintain compatibility with
RFC5245 and will allow future extension of ice-sip-sdp to support FQDN.

I am not in favor of 1, since this introduces a fair amount of scope creep.
Option 3 is neither backwards no forwards compatible.

Regards,
_____________
Roman Shpount

On Mon, May 20, 2019 at 6:21 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> I am fine with removing FQDN, but keep in mind that such “negotiated
> extension” would then have to be defined in order to progress the mdns-ice
> draft.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Bernard Aboba <[email-masked]>
> *Date: *Monday, 20 May 2019 at 23.07

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2019 22:38:39 +0000

I am fine with option 2. I just wanted to remind the community what it means for mDNS, to avoid any whoops-we-didn’t-think-of-that’s further down the road.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Monday, 20 May 2019 at 23.32
To: Christer Holmberg <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

1. Define how FQDN is handled
2. Specify that FQDN is allowed in the connection-address of ICE candidate, but that such candidates MUST be ignored unless some future extension is negotiated.
3. Prohibit using FQDN in the connection-address

I am in favor of option 2, since it will maintain compatibility with RFC5245 and will allow future extension of ice-sip-sdp to support FQDN.

I am not in favor of 1, since this introduces a fair amount of scope creep. Option 3 is neither backwards no forwards compatible.

Regards,
_____________
Roman Shpount

On Mon, May 20, 2019 at 6:21 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Date: Monday, 20 May 2019 at 23.07
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>, Flemming Andreasen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

Regards,

Christer

      one IP address.

Thanks
Suhas

Thanks

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 May 2019 19:03:13 -0400

On Mon, May 20, 2019 at 6:38 PM Christer Holmberg <
[email-masked]> wrote:

> I am fine with option 2. I just wanted to remind the community what it
> means for mDNS, to avoid any whoops-we-didn’t-think-of-that’s further down
> the road.
>
>
>
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.

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.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2019 23:14:50 +0000

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 May 2019 18:55:24 -0700

"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 <
[email-masked]> 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
> fully qualified domain names (FQDNs).  When >parsing this field, an agent
> ignore candidate lines >that include candidates with FQDN or IP address
> in candidate can be defined in the future specification. If candidate >with
> resolution result and the "c=" connection >address MUST be set to FQDN.
> "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
>
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 May 2019 22:34:00 -0400

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

> <connection-address>:  is taken from RFC 4566 <https://tools.ietf.org/html/rfc4566> [RFC4566 <https://tools.ietf.org/html/rfc4566>].  It is the
>> ><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:
>>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 May 2019 19:51:25 -0700

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 May 2019 23:18:50 -0400

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.

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 <[email-masked]> 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.
>
>>> "If FQDN is allowed but ignored, this will allow "legacy"
>>> 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."
>>>
>>>> So far this is my proposal for ice-sip-sdp connection address
>>>> definition which should implement option 2:
>>>>

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 20 May 2019 22:01:48 -0700

> 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

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2019 11:05:35 +0000

Hi,

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

I agree.

As far as 8445 is concerned, each candidate is associated with an IP address and port. FQDN resolutions, encoding of the candidates etc are outside the scope.

Regards,

Christer

On Mon, May 20, 2019, 22:51 Bernard Aboba <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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

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

Minor change suggestion:

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 May 2019 09:37:25 -0400

On 5/21/19 1:01 AM, Suhas Nandakumar wrote:
>
>
> On Mon, May 20, 2019 at 8:19 PM Roman Shpount <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>
> 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
>
>         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
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             What do you suggest?
>
>             On Mon, May 20, 2019, 21:55 Bernard Aboba
>             <[email-masked] <mailto:[email-masked]>>
>             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
>                 [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
>                 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:
>                 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
>                 <[email-masked]
>                 <mailto:[email-masked]>> 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.
>
>                     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
>                     "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
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2019 14:36:18 +0000

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.

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 <[email-masked]> on behalf of Flemming Andreasen <[email-masked]>
Date: Tuesday, 21 May 2019 at 14.40
To: Suhas Nandakumar <[email-masked]>, Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

On Mon, May 20, 2019 at 8:19 PM Roman Shpount <[email-masked]<mailto:[email-masked]>> 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

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

Minor change suggestion:

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 21 May 2019 07:58:03 -0700

On Tue, May 21, 2019 at 7:36 AM Christer Holmberg <
[email-masked]> wrote:

> 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 <[email-masked]> on behalf of Flemming Andreasen <
> [email-masked]>
> *Date: *Tuesday, 21 May 2019 at 14.40
> *To: *Suhas Nandakumar <[email-masked]>, Roman Shpount <
> [email-masked]>
> *Cc: *Christer Holmberg <[email-masked]>, "[email-masked]"
> <[email-masked]>
> ice-sip-sdp does not seem like a good idea, and we need to move this draft
> forward.
>
> Thanks
>

---

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

On Tue, May 21, 2019 at 1:02 AM Suhas Nandakumar <[email-masked]>
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.
>>
>
All I am saying that RFC 8445 does not deal with FQDN resolution. It accept
a list of candidates with already resolved addresses. Address resolution is
supposed to be handled an some other draft such as ice-sip-sdp or ITS
EXTENSION (added emphasis).

If we decide to move FQDN resolution into separate draft, it is fine, but
it will not be an RFC 8445 update.

Regards,
_____________
Roman Shpount

---

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

> ice-sip-sdp does not seem like a good idea, and we need to move this draft
I agree that FQDN must be in a separate draft. It should not, however, be a
part of RFC 8445 since it is outside of scope for the draft.
_____________
Roman Shpount

---

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

> provider of the candidates. If so, it needs to be more clear.
The last portion definitely needs to be clarified. I am trying to provide
procedures for Verifying ICE support when FQDN is used in default ICE
candidate. In this case, agent which receives such offer must verify ICE
support without the need for FQDN resolution. My suggestion is to use
literal FQDN value from default candidate in c= line and do not validate
address family and type (do not detect m= line mismatch if address family
and type are not what is result of some unspecified resolution procedure).
_____________
Roman Shpount

---

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

On Tue, May 21, 2019 at 10:58 AM Suhas Nandakumar <[email-masked]>
wrote:

> [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 ?
>
>>
>>
Ignore candidates with FQDN is the minimal viable behavior. I think details
of FQDN resolution, including interop with legacy implementations which use
FQDN should be a part of the separate draft that specifically addresses
FQDN handling. This is not ideal, but, since figuring out the best strategy
for FQDN handling will take some time, this will allow to publish
ice-sip-sdp as quickly as possible.

Regards,
_____________
Roman Shpount