Re: [v6ops] DNSv6 Proxy !

Owen DeLong <owen@delong.com> Tue, 21 May 2013 14:27 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A2621F97E9 for <v6ops@ietfa.amsl.com>; Tue, 21 May 2013 07:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzWkui2vGTMp for <v6ops@ietfa.amsl.com>; Tue, 21 May 2013 07:27:03 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E721F97E8 for <v6ops@ietf.org>; Tue, 21 May 2013 07:27:03 -0700 (PDT)
Received: from [172.20.10.2] (75.sub-70-192-4.myvzw.com [70.192.4.75]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r4LEOaCN008265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 May 2013 07:24:41 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r4LEOaCN008265
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1369146285; bh=gKChbZs6geYl9lND9oyqp7vsFAQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c1eyballYtef1L0iHvDw9lkT+rIIg2hVGflthq3B99QAg9Sl0YxeQJt6E/JQEW0s1 HOzRT7FLxcDphAdAfWWuyqHMedKO5ypVNIhIcSrcfcMEM6yCF8IEay+gLRw6/xYJgR EbxL6/vrACdpmBJNhqpLDH6hc2rxfV25C2JxiJJU=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com>
Date: Tue, 21 May 2013 07:24:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <583A07B7-AF3F-4DA5-B76C-E827B0A80CDD@delong.com>
References: <B14A62A57AB87D45BB6DD7D9D2B78F0B116ACDFD@xmb-rcd-x06.cisco.com> <B14A62A57AB87D45BB6DD7D9D2B78F0B116ACE79@xmb-rcd-x06.cisco.com> <2D09D61DDFA73D4C884805CC7865E611302C6230@GAALPA1MSGUSR9L.ITServices.sbc.com>
To: "STARK, BARBARA H" <bs7652@att.com>
X-Mailer: Apple Mail (2.1503)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 21 May 2013 07:24:45 -0700 (PDT)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] DNSv6 Proxy !
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 14:27:05 -0000

On May 21, 2013, at 6:52 AM, "STARK, BARBARA H" <bs7652@att.com> wrote:

>> I just realized that neither RFC6204, nor the bis draft
>> (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-01#section
>> -5.1) have added any specifics for what IPv6 address should the CPE router
>> use while executing the DNS proxy function (if enabled).
>> 
>> Should it use the IPv6 address assigned to its WAN interface (which is to be
>> used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the
>> address assigned to its LAN interface via DHCPv6 PD ?
> 
> IMO, the default behavior of the CE router would be to use default address selection as described in RFC 6724. Since 6204bis (and RFC 6204) requires the CE router to be an IPv6 node per RFC 6434, RFC 6434 requires address selection per RFC 3484, and RFC 6724 obsoletes RFC 3484, I think this is covered.
> 

Technically true, but given the chain of RFCs you had to put together to make that point, restating it clearly here might not be such a bad thing, no?

> Since the DNSv6 query is being sent out the WAN interface, I would expect the CE router to select an address from among those it considers appropriate for traffic that it originates and sends out over that WAN interface. I would hope that access providers would not be surprised by a CE router considering a globally scoped, preferred, and valid address assigned to its WAN interface as being appropriate for traffic that the CE router sends out over the WAN interface. The idea that a CE router is supposed to interpret such an address assigned to its WAN interface as being reserved for a special purpose (CPE management) strikes me as odd. If the access provider wants to assign a special management address to the WAN interface, it would probably be best to assign an address that would not end up being the CE router's first pick for other traffic, per RFC 6724 guidance.

This incorporates a number of (not necessarily correct) assumptions about how things happen in the real world.

It is not at all unlikely that a provider would, e.g. design their network with one subset of their allocation used for management of CPE devices while using another subset for assigning customer addresses for general customer use. My understanding of RFC 6724 is that if the CPE were assigned (e.g.)
	2001:db8:1234::2 as a management address and
	2001:db8:9876::/48 for subscriber usage with the WAN link getting
	2001:db8:9876::2 with default gateway 2001:db8:9876::1, then
It would be ambiguous as to which of 2001:db8:1234::2 or 2001:db8:9876::2 would be used to source traffic by default.

Owen