Re: [MMUSIC] FQDN support in ice-sip-sdp

Suhas Nandakumar <suhasietf@gmail.com> Thu, 11 April 2019 08:03 UTC

Return-Path: <suhasietf@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658AC12029B for <mmusic@ietfa.amsl.com>; Thu, 11 Apr 2019 01:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcAr1hoywtSi for <mmusic@ietfa.amsl.com>; Thu, 11 Apr 2019 01:03:30 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25601202AD for <mmusic@ietf.org>; Thu, 11 Apr 2019 01:03:28 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id n4so2967340vsm.3 for <mmusic@ietf.org>; Thu, 11 Apr 2019 01:03:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rsWukwhmvaf7CamjeLYtDRZZhotxpD+ZuAIrMqd77xs=; b=QYgCcRl2idK+SZ4HpcA3dw/PAUDOKBQBhAawMLu15dASSV5wMlBHuoJtA0no0VWKT/ klv4bpot0E2pD9YgBN8ipLSViia4V43JegbX7WijzaVTFuFTHOEouDYi/v6YQhL2OHBD voAFINTWchEMqsXPunxCqfq8MtcD69mEAx4cUIxTCoSGLY5z4AN3cLdXfOiBXtQoa/z+ BxVFL1/pHKKrj+3Zn3xgQDha9Q5KEpQvaN3S1AkTdvvi/stTO24fvVAFJPLa7uP0IA6L enNbJqD9LNUhkBhU/NEt5JC/gPFIkNs7MF2Rm1gRwx/Yq7dics/k39/uYrL+Uf5HJYAy C0HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rsWukwhmvaf7CamjeLYtDRZZhotxpD+ZuAIrMqd77xs=; b=d4LxGAaP/IiduGM6vdfyCDirBFqzaMbKiSZYLbrWQCVAFijLQ8uGYvNwwv7zNPRl8i NtzB4dhSmPdRi7gvFSNHDHRTrB41c1+WxBauFNpxaVrilRc/t2tv4GPdBRMdsI2Mb3Zk e8eS1Id/v2wL48U2tofqs0el4fjvowgdUNu+Ir/Lgffpb6gdFbgSxx/aHccFjo3LiyYQ VYyNnquA9IDPTiaPZoKlLCvDMRbnMyGXXyUFm2OXctNIRpbxM/THIWaKGAObU6hb8G7m KpxexNnPjcFGsuU9UlBcH59AtvVWvY5D1ZNugaBv4f7WIzAj55aVOBw3DszQGZ/qDoe8 cJFA==
X-Gm-Message-State: APjAAAWId//3fEHcc4a0tgSt/bAv/Vms1JXE2Nq29FyfSoTtwndkhvAK yRQ5hprFawzI35JV1KL36BlIIF0M87ou2WDQdsw=
X-Google-Smtp-Source: APXvYqzBnTdxdVHcB7mNO1dijLc8nsfNVO4onU/5K85u+MCP1lY7Ya02muoOPmeywLLhzBPwUH/UX9H7LzxYGXeWEhQ=
X-Received: by 2002:a67:80c8:: with SMTP id b191mr26298141vsd.184.1554969807868; Thu, 11 Apr 2019 01:03:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5OKxux4s=4TtA7vQT0X-u+3RS+MVHG=RjgGDHWQ5H1k0OdLg@mail.gmail.com> <CAMRcRGTmYB-CMXA5ToPhdPtLrTeKmdeZCLT-ecxfTYGHEh-HMQ@mail.gmail.com> <CAD5OKxsPDagYEFFMhxGnm3H+gAWEsKmt41rw44GCmorneVytzQ@mail.gmail.com> <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com> <CAD5OKxsbQhU_1ADsnbcHUtfoiK96We004AEmtajO-EvY0dRd7Q@mail.gmail.com>
In-Reply-To: <CAD5OKxsbQhU_1ADsnbcHUtfoiK96We004AEmtajO-EvY0dRd7Q@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Thu, 11 Apr 2019 01:03:17 -0700
Message-ID: <CAMRcRGSWEQ9UVJUZy9rMzX=HxDBihYNDUfSyqZcR0d=msJXZXA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Suhas Nandakumar <suhasietf@gmail.com>, mmusic WG <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>
Content-Type: multipart/alternative; boundary="00000000000008d78b05863c9fa8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/yVneFIkDs4xPS8oETsp9tAzECxs>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 08:03:36 -0000

On Wed, Apr 10, 2019 at 12:36 PM Roman Shpount <roman@telurix.com> wrote:

> On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>> >Limiting FQDN scope to resolving to just one address is an
>> unimplementable requirement. Currently on large number of devices, FQDN
>>
>> >which is supposed to resolve to IPv4 address only, will resolve to both
>> IPv6 and IPv4 addresses. For instance on virtually all IOS and most
>> >of the Android devices on mobile networks FQDN pointing to IPv4 returns
>> results for IPv6 as well. Essentially what we are specifying now is
>> >that ICE candidates with FQDN address MUST be ignored.
>>
>>
>>
>> Isn’t the main reason for allowing FQDN to enable usage of mDNS?
>>
>
>  It is now. Nothing in the latest language that I propose prohibits mDNS
> draft define how FQDN are supposed to work when mDNS is used. All my
> language states that default treatment for FQDN is to ignore it which keeps
> mDNS backwards compatible. I would also suggest adding an ICE option to
> specify that mDNS is supported. This being said, I am not sure mDNS
> prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is
> likely going to end up with two addresses for a single candidate.
>
> In my opinion, the current ICE procedures assumes one IP address:port per
>> candidate. If we allow a candidate to be associated with multiple IP
>> addresses:ports, we would have to modify the ICE procedures in order to
>> handle that: how a candidate can be part of multiple foundations (one for
>> each resolved IP address:port), how the freezing/unfreezing procedure work,
>> whether connectivity checks are sent to all resolved addresses, how the
>> state of the candidate is set if one IP address:port succeeds but another
>> doesn’t. Or, should the candidate be split into multiple candidates (one
>> for each resolved IP address:port)? Etc etc etc etc etc. All of that could
>> probably be done, but I think it would be quite a bit of work- an update
>> (or even a bis) to RFC 8445. It is **NOT** an ice-sip-sdp specific issue
>> in my opinion.
>>
>
> I am not suggesting changing that only one address is supported per
> candidate. What I am suggesting is that candidate needs some sort of hint
> when FQDN is used to specify how address should be resolved. Here is my
> proposed solution:
>
> Add a candidate extension which specifies candidate address type,
> something like addrtype which can be set to "inipv4" or "inipv6". If IP
> address is used and it does not match the addrtype candidate extension,
> this candidate is ignored. When FQDN is used, it is resolved using A DNS
> request when addrtype is inipv4 or not present and using AAAA DNS request
> when addrtype is inipv6. Address family in c= line, when FQDN is a default
> candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be
> IP IPV6 if addrtype is inipv6
>
> Example:
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local
> 60454 typ host *inipv4*
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local
> 60454 typ host *inipv6*
>
>
I am not for or against the proposal. I am sure its fine.  I am concerned
about the scope of this change and current implementations who are willing
to support this new extension. Why can't this be in a total new draft ?


>
>
> This keeps each candidate line to one address and works in cases when FQDN
> resolves to one IPv4 and one IPv6 address due to something like DNS64.
>
> Regards,
>  _____________
> Roman Shpount
>
>