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 > >
- [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Suhas Nandakumar
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Suhas Nandakumar
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Suhas Nandakumar
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg
- Re: [MMUSIC] FQDN support in ice-sip-sdp Roman Shpount
- Re: [MMUSIC] FQDN support in ice-sip-sdp Christer Holmberg