IETF Logo Mail Archive

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

Gert Doering <gert@space.net> Sun, 01 June 2014 10:24 UTC

Return-Path: <gert@Space.Net>
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 6A9481A01D4 for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 03:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 jDetkNucXyw1 for <v6ops@ietfa.amsl.com>; Sun, 1 Jun 2014 03:24:16 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F501A01D3 for <v6ops@ietf.org>; Sun, 1 Jun 2014 03:24:15 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C499460B34 for <v6ops@ietf.org>; Sun, 1 Jun 2014 12:24:08 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 882C860AED for <v6ops@ietf.org>; Sun, 1 Jun 2014 12:24:08 +0200 (CEST)
Received: (qmail 57822 invoked by uid 1007); 1 Jun 2014 12:24:08 +0200
Date: Sun, 01 Jun 2014 12:24:08 +0200
From: Gert Doering <gert@space.net>
To: Mark Andrews <marka@isc.org>
Message-ID: <20140601102408.GH46558@Space.Net>
References: <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <m1WqqZ4-0000DqC@stereo.hq.phicoh.net> <20140531213133.GB46558@Space.Net> <20140531222321.8A5D8171A140@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="ley0jF/Xzz4aC/u2"
Content-Disposition: inline
In-Reply-To: <20140531222321.8A5D8171A140@rock.dv.isc.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1Auzckysc1hTITBHi36Y6bljfF4
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: Sun, 01 Jun 2014 10:24:18 -0000

Hi,

On Sun, Jun 01, 2014 at 08:23:21AM +1000, Mark Andrews wrote:
> > > But I have nothing to update my DNS zones. How do I reflect which links 
> > > are up or down? Is there even a draft for that? What's the BCP for TTL
> > > values, DNSSEC, etc?
> > 
> > This is where things get interesting.  You, Owen, I are not "the 99% home
> > users out there" - home users don't do DNS zones, because they do not 
> > control a DNS server...  (they do mDNS because it's automatic and works
[..]
> The IETF has published exactly one method for updating the DNS (RFC 2136).
> It has standardized several methods for securing that update.

While technically fully correct, this is completely missing the point :-)

 - how does the homenet CPE/host know *which* domain to update?
 - how does the homenet CPE/host know *how* to update this domain (end 
   users do not understand "entering keys in bind config on authoritative 
   name servers, and then copy these keys to their CPE")?
 - *when* should the CPE/host do the update, particularily, when one of the 
   ISP uplinks goes down, *should* it remove the records using that ISP's
   prefix?  If yes, after which time of non-availability?  (The ISP might
   never come back, it might be a move to a new ISP, after all)
 - if, on the same ISP, the prefix changes, how should the update look
   like?  Flash replace, staggered add/remove?

these are the interesting questions.  The mechanics of doing a zone update
via DNS protocol are interesting for DNS software implementors, but fairly 
uninteresting as far as the yet-unsolved questions surrounding a CPE in
a non-managed home or SME network go :-)

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

v2.23.0 | Report a Bug | By Email