Re: [sipcore] comments on draft-ietf-sipcore-dns-dual-stack-02

Brett Tate <brett@broadsoft.com> Fri, 19 June 2015 13:32 UTC

Return-Path: <brett@broadsoft.com>
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 989A21A904A for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 06:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.279
X-Spam-Level:
X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 w_g_t9jXYtWn for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 06:32:30 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 84B031A9043 for <sipcore@ietf.org>; Fri, 19 Jun 2015 06:32:30 -0700 (PDT)
Received: by wibdq8 with SMTP id dq8so18813419wib.1 for <sipcore@ietf.org>; Fri, 19 Jun 2015 06:32:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=3cZSqs5sGyr40RNFnu4216yW4tYfuQ3UGQsac+8nKE8=; b=VOVY73mHS53JRkAL8ebI7uVfOCRJgmWfN+5JyoCTjG66HfGmhK95dTVGAyJpgvnFv+ 1x/dPkDwe4u2gSIjT2qHQXaj1A/gH86RdABI9KvbbPgBDhxU4Bk3VHb/+GIAWR4qcfi3 6MbUhmRTHKEFkXkcCZ+NqOX/tGznYi1zWyXRlhRedl3tkKWlIgiRPJ3loTWpXzAd1sVg oFr3uUUg707ncswByxgu2tTrf10WWLU9z8JYnRo2+8+ke/EIirL0EBL0ptJNX0IzDyUA 90bIi+KWunyBH/PhO9czglVR5XqSjPu4yr9578q1skYOqNXNO91tjSasTctRrPkSmfAW 0mRw==
X-Gm-Message-State: ALoCoQkIPOb8ur5uYQn8qlmV6LF+nqPfJMCqEOyrM6mCM6lVG2pNOa+85/Dv2hURdljg136rTt0Q
X-Received: by 10.180.24.165 with SMTP id v5mr6680791wif.63.1434720749184; Fri, 19 Jun 2015 06:32:29 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
References: <E56B3AF7-6874-4A66-8426-78A98DA435B4@cisco.com>
In-Reply-To: <E56B3AF7-6874-4A66-8426-78A98DA435B4@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIXj57ODAPoXUKD6yohUcxuzSKVsZ0l+PTw
Date: Fri, 19 Jun 2015 09:32:27 -0400
Message-ID: <ecaa9285c817548b0f18c0a1e7725dd5@mail.gmail.com>
To: 🔓Dan Wing <dwing@cisco.com>, sipcore@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/AgN1Os5ktSrCNLoymu2HzxDQrmo>
Subject: Re: [sipcore] comments on draft-ietf-sipcore-dns-dual-stack-02
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: Fri, 19 Jun 2015 13:32:32 -0000

> The actual recommendation at end of section 4.1 only says:
>
>   The dual-stack client SHOULD perform an A and AAAA record lookup
>   of the domain name and add the respective IPv4/IPv6 addresses to
>   the list of IP addresses to be contacted.
>
> but it doesn't say if A or AAAA should be placed at the beginning
> of the list, end of the list, or scattered randomly.  It probably
> matters, especially if we envision a long list of AAAA and long
> list of A records, and we also envision an outage of one address
> family.

It may or may not matter (although I agree that the draft should provide a
recommendation).  Similarly, this draft may improve or worsen call setup
delays.

The sender doesn't know if the A/AAAA records reflect the same device or
different devices.  If the records reflect the same device and the device is
down, the draft slows down the advancing to the next SRV record.

If a network administrator had been relying upon the "A or AAAA" behavior of
RFC 3263, they might desire DNS changes based upon the draft's change to "A
and AAAA".  If they do not know if the relevant devices behave per the draft
or RFC 3263, they'd likely want to configure things to work adequately for
both behaviors.