Re: [MMUSIC] FQDN Support Final Vote

[Roman Shpount <[e-mail]>]

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


On Tue, May 21, 2019 at 11:26 AM Suhas Nandakumar <[e-mail]>
wrote:

> Hi All
>
>   Below i have included 4 flavors of suggested text for FQDN support in
> ice-sip-sdp.  Let's agree on one and go with it (even it doesn't make us
> entirely happy).
>
>
> *RFC5245 Version *
> "<connection-address>: is taken from RFC 4566
> <https://tools.ietf.org/html/rfc4566> [RFC4566
> <https://tools.ietf.org/html/rfc4566>]. It is the
>
>       IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs).  When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6.  An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized.  An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address.  In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A.  If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing.
>
>
> *ice-sip-sdp pre-22 version1*
>
>
> <connection-address>:  is taken from RFC 4566 [RFC4566].  It is the IP address of the candidate.  When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value -- the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>