IETF Logo Mail Archive

Re: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns

Ray Bellis <ray@bellis.me.uk> Tue, 15 March 2016 11:22 UTC

Return-Path: <ray@bellis.me.uk>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DAD12D8C5; Tue, 15 Mar 2016 04:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 iGb4K0DX-KzT; Tue, 15 Mar 2016 04:22:09 -0700 (PDT)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF11812D546; Tue, 15 Mar 2016 04:22:09 -0700 (PDT)
Received: from [46.227.151.81] (port=52138 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1afn39-0002lj-98 (Exim 4.72) (return-path <ray@bellis.me.uk>); Tue, 15 Mar 2016 11:22:07 +0000
To: Markus Stenberg <markus.stenberg@iki.fi>
References: <56E7E35D.6040108@bellis.me.uk> <2514F81A-CDC6-4F90-A76D-816A8F4EEDC4@iki.fi>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <56E7F060.1040004@bellis.me.uk>
Date: Tue, 15 Mar 2016 11:22:08 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <2514F81A-CDC6-4F90-A76D-816A8F4EEDC4@iki.fi>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/BSKfuOo4el4cRFzQNmWIfPg5E6U>
Cc: draft-stenberg-mif-mpvd-dns@ietf.org, mif@ietf.org
Subject: Re: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2016 11:22:11 -0000


On 15/03/2016 11:08, Markus Stenberg wrote:
> Actually we considered it a feature and not a bug, i.e. subdelegation
> would still result in same PVD available. I am not sure your scheme
> would work with subdelegation though.

OK, I see that, but I still think you have a problem since:

   2001:0:0:0::/64

and

   2001:0:0:0:0::/80

and even:

   2001::/16

will end up at the same domain name.

> Given broad example, ISP has /40 for home users, but ultimately the
> prefix in use may be e.g. /64 (or even something more narrow). Having
> the _pvd.* in 'all' prefix lengths would be obviously available, or
> performing (up to 128) lookups with subsequently shorter/longer
> prefix lengths.
> 
> I am not sure how client would know to start lookups from /40, or
> from /56 assigned to a home, if the link has /64.

In RFC 7216 we took a "minimal" tree climbing approach, putting the
records at "common" LIR / RIR prefix boundaries of /64, /56, /48, or
/32.   Anything more would have angered the DNS Gods...

Is there no other way for the client to learn the size of the upstream
PD from which its /64 has been carved out?

Ray

v2.23.0 | Report a Bug | By Email