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

Markus Stenberg <markus.stenberg@iki.fi> Tue, 15 March 2016 11:35 UTC

Return-Path: <markus.stenberg@iki.fi>
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 3307412D991; Tue, 15 Mar 2016 04:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 WBAFS4SITqJK; Tue, 15 Mar 2016 04:35:48 -0700 (PDT)
Received: from johanna3.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB7112D978; Tue, 15 Mar 2016 04:35:47 -0700 (PDT)
RazorGate-KAS: Status: not_detected
RazorGate-KAS: Rate: 0
RazorGate-KAS: Envelope from:
RazorGate-KAS: Version: 5.5.3
RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29
RazorGate-KAS: Lua profiles 69136 [Nov 12 2014]
RazorGate-KAS: Method: none
Received: from [192.168.200.82] (192.194.110.125) by johanna3.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E79371000E44B1; Tue, 15 Mar 2016 13:35:46 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <56E7F060.1040004@bellis.me.uk>
Date: Tue, 15 Mar 2016 13:35:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EC649AC-8FDB-4B7E-B746-8173825ECF44@iki.fi>
References: <56E7E35D.6040108@bellis.me.uk> <2514F81A-CDC6-4F90-A76D-816A8F4EEDC4@iki.fi> <56E7F060.1040004@bellis.me.uk>
To: Ray Bellis <ray@bellis.me.uk>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/ikGSY069w90yPNV4Y8sZZbSuUgs>
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:35:50 -0000

> On 15.3.2016, at 13.22, Ray Bellis <ray@bellis.me.uk> wrote:
> 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.

Not necessarily. Your home _could_ provide (split horizon) different records than someone else's home. Or ISP could subdelegate that part to your home (then again, I am not sure I would bet on it).

>> 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?

Not without some new option in RA/DHCP I think.

Cheers,

-Markus