Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

Mark Andrews <marka@isc.org> Mon, 02 June 2014 15:08 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0D21A021F for <v6ops@ietfa.amsl.com>; Mon, 2 Jun 2014 08:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.252
X-Spam-Level:
X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 5EQEPmPvHuK7 for <v6ops@ietfa.amsl.com>; Mon, 2 Jun 2014 08:08:42 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3492E1A0141 for <v6ops@ietf.org>; Mon, 2 Jun 2014 08:08:42 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 835273493A0; Mon, 2 Jun 2014 15:08:36 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B19A160067; Mon, 2 Jun 2014 15:13:40 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 257B6160057; Mon, 2 Jun 2014 15:13:40 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 179BC1734B4E; Tue, 3 Jun 2014 01:08:03 +1000 (EST)
To: Gert Doering <gert@space.net>
From: Mark Andrews <marka@isc.org>
References: <2A4B72CD-EDF3-4D11-AC39-B65892F9173F@nominum.com> <CAKD1Yr2NH4Kca4EvhjN2XnDbt8F2eS56ipxu3npH9yOh1bmQaA@mail.gmail.com> <F12F173B-9FF2-4EF8-B11E-33AEDA24961F@nominum.com> <CAKD1Yr1cGx7UfxZaEhm7oHA5PLvghVc52oPVkEQF90_7Vm__vw@mail.gmail.com> <1FDC3A7F-15EC-4397-AF3E-10F86EA04228@nominum.com> <538BDA84.6030800@bogus.com> <37D09BEE-FEDF-4514-8CEB-62959A89C3FF@nominum.com> <538BE13C.7050900@bogus.com> <D743D805-0A93-4E6A-84D8-FEAC8D27F267@nominum.com> <20140602025833.A659C1723F0A@rock.dv.isc.org> <20140602081853.GQ46558@Space.Net>
In-reply-to: Your message of "Mon, 02 Jun 2014 10:18:53 +0200." <20140602081853.GQ46558@Space.Net>
Date: Tue, 03 Jun 2014 01:08:03 +1000
Message-Id: <20140602150803.179BC1734B4E@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HigpXShuHn-j6QS5JDMsIJ1wDrU
Cc: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>, V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 02 Jun 2014 15:08:43 -0000

In message <20140602081853.GQ46558@Space.Net>, Gert Doering writes:
> Hi,
> 
> On Mon, Jun 02, 2014 at 12:58:33PM +1000, Mark Andrews wrote:
> > There is also nothing to prevent a stack trying multiple source
> > addresses when it hasn't been explicitly bound to a source address
> > by the application.  
> 
> Well, yes, nothing *prevents* this.  But given lack of IETF guidance on
> this, stack implementors do not seem to be keenly interested in actually
> implementing this.
> 
> (Does BIND do this...?)

We don't automatically try multiple source addresses per family but
you can specify different sources addresses for different destination
addresses.

At this point multiple PA prefixes are not common yet.

ULA + PA (or PI) just works at the moment.

That said I would most probable implement it something like <D1,S1>,
<D2,S2>, <D3,S1>, <D1,S2>, <D2,S1>, <D3,S2> assume S1 and S2 are from
different PA prefixes.

On top of detecting network failures nameservers also have to deal
with broken nameservers / firewalls that drop queries because they
don't like something in the query despite it being perfectly in
spec.

Then there is RRL processing which drops queries if the server sees
excesive traffic as part of amplication mitigation.

> Gert Doering
>         -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org