IETF Logo Mail Archive

Re: [sipcore] IPv6 in the sip core wg

"Olle E. Johansson" <oej@edvina.net> Tue, 10 December 2013 19:21 UTC

Return-Path: <oej@edvina.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18001AE01B for <sipcore@ietfa.amsl.com>; Tue, 10 Dec 2013 11:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 p1gpKadEM1GP for <sipcore@ietfa.amsl.com>; Tue, 10 Dec 2013 11:21:32 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD41ADFF5 for <sipcore@ietf.org>; Tue, 10 Dec 2013 11:21:31 -0800 (PST)
Received: from [192.168.101.63] (unknown [72.46.244.148]) by smtp7.webway.se (Postfix) with ESMTPA id EBDE393C2A1; Tue, 10 Dec 2013 19:21:23 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <FFB57ECD-8CDB-44E9-9A3F-5418AAC01C5B@iii.ca>
Date: Tue, 10 Dec 2013 14:21:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net>
References: <C774C9EA-4E79-4846-A834-BF86D2DD8018@edvina.net> <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <CAHBDyN7AT0m7P5miYa+hCvh55Ov3f1Nc-U1zUK6H-0i4aHTW+g@mail.gmail.com> <52A7486E.2090005@alum.mit.edu> <FFB57ECD-8CDB-44E9-9A3F-5418AAC01C5B@iii.ca>
To: Cullen Jennings <fluffy@iii.ca>
X-Mailer: Apple Mail (2.1822)
Cc: Olle E Johansson <oej@edvina.net>, SIPCORE WG <sipcore@ietf.org>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
Subject: Re: [sipcore] IPv6 in the sip core wg
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 19:21:34 -0000

On 10 Dec 2013, at 12:14, Cullen Jennings <fluffy@iii.ca> wrote:

> 
> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
>>  June 2014  Updated procedures for dual-stack server handling of SIP
>>   URIs containing domain names
> 
> Before we use update, can someone tell me what normative text of the current RFCs need to be changed?
> 

That's part of the problem, RFC 3263 is not very clear to me in indicating what exactly is normative. If you read our draft, you will see that we point to a few sections that clearly says that a UA needs to look up "A or AAAA" records, which has been proven wrong and doesn't follow the intention of the DNS SRV RFC. If this was unintentional or normative, I don't know, but it's written enough times to cause issues in implementations and have been copied to other documents, like the MSRP RFC.

We need to clarify that a SIP implementation needs to follow the DNS SRV RFC and look up all addresses for a host name (ipv4, IPv6 or future address families) and test them all before moving to the next priority and host.

I've checked this with members of the IETF DNS directorate two times now, and they agree with this.

When we clarified/updated/extended/informed the audience - developers - about this, we need to get down to how to connect - serially, in parallell, in reverse random order controlled by the phases of the moon or other planets - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs like in HTTP would not work unless we have both A and AAAA records. RFC 3263 doesn't really indicate that.

Someone else needs to help out to clarify to me what is really normative in 3263 and what the relationship between 3263 and RFC 2782 really is - if RFC 2782 is the normative one and RFC 3263 just can be seen as a happy story that points to 2782 without making any normative changes, we might have to clarify that in an informational document and move on to connection setup in a dual stack world. If RFC 3263 changes the behaviour intended by 2782 and really forces a developer to select A or AAAA records, then we need to change that behaviour.

Either way, we have work to do in ths wg.
/O

v2.23.0 | Report a Bug | By Email