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

Mark Andrews <marka@isc.org> Sat, 31 May 2014 22:58 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 180801A011C for <v6ops@ietfa.amsl.com>; Sat, 31 May 2014 15:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level:
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 uMGfTvC_hOy7 for <v6ops@ietfa.amsl.com>; Sat, 31 May 2014 15:58:42 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AF45F1A00EC for <v6ops@ietf.org>; Sat, 31 May 2014 15:58:42 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 3824134945D; Sat, 31 May 2014 22:58:37 +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 B0033160067; Sat, 31 May 2014 23:03:33 +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 71C7F16004E; Sat, 31 May 2014 23:03:33 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A1E48171A332; Sun, 1 Jun 2014 08:58:03 +1000 (EST)
To: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>
From: Mark Andrews <marka@isc.org>
References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <m2iooq4oqi.wl%randy@psg.com> <5385762E.5020901@dougbarton.us> <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> <20140531214908.10FEE1719BB4@rock.dv.isc.org> <m1WqrFK-0000BHC@stereo.hq.phicoh.net>
In-reply-to: Your message of "Sat, 31 May 2014 23:55:22 +0200." <m1WqrFK-0000BHC@stereo.hq.phicoh.net>
Date: Sun, 01 Jun 2014 08:58:03 +1000
Message-Id: <20140531225803.A1E48171A332@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K4Nazk43rf3woBCLQjW8hfHxzbs
Cc: 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: Sat, 31 May 2014 22:58:44 -0000

In message <m1WqrFK-0000BHC@stereo.hq.phicoh.net>, Philip Homburg writes:
> In your letter dated Sun, 01 Jun 2014 07:49:08 +1000 you wrote:
> >You have UPDATE + TSIG or SIG(0).  This is basically what Microsoft
> >do with Active Directory except they use GSS-TSIG for about 15 years
> >now.  UPDATE and DNSSEC just work and have for over a decade now.
> >Happy Eyeballs has proved that you don't need change the DNS for
> >link state changes.  IPv4 vs IPv6 is no different to PA1 vs PA2.
> >HE is all about the client working around a dead link.
> 
> My router is going to update DNS using UPDATE + TSIG? How does my router know
> then names of my servers (or the actual addresses)?
> 
> Are servers going update themselves?

Why not?  They know their own addresses.  They know their name.  If
you have a UNIX/Linux based box that shipped in the last 15 years
you have the tools to do this.  Having this done when the addresses
change is a matter of writing a small daemon or integrating it into
the DHCP client.

% nsupdate -k keyfile
update delete <servername> AAAA
update add <servername> 3600 AAAA <address1>
update add <servername> 3600 AAAA <address2>
update add <servername> 3600 AAAA <address3>
send
%

This deletes all the AAAA records and then adds in all the current
addresses.  This is a atomic transaction.  The nameserver adds
DNSSEC signatures if they are appropriate for the zone.

Similar for A records.

keyfile could contain a TSIG key or a KEY for SIG(0)

You can also do split horizon updates if you want to using multiple
TSIG keys to select the zone instance to be updated.

> Is any of that spelled out?
> 
> I have no idea what software you are using, but only a tiny fraction of
> the software I'm using actually uses happy eyeballs. 
> 
> You suggest that every possible piece of software should implement HE?

Yes.  RFC 1123 told every developer for the last 2 decades to support
multi-homed servers.

http://users.isc.org/~marka/ has simple example code for how to do
this for TCP clients.  UDP clients are slightly more complicated
as you have to it higher up the stack.  The client side of DNS
servers has been doing this sort of stuff for multiple decades now
but instead of trying to do a single connection they are dealing
with thousands of connections.

The code is slightly more complicated than that published in the
getaddrinfo man page but not much more.

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org