Re: IPv6, was IPv10

Mark Andrews <marka@isc.org> Fri, 30 December 2016 00:39 UTC

Return-Path: <marka@isc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA5F129530 for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 16:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] 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 i1UWBGQBa3ct for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 16:39:40 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612E8129486 for <ietf@ietf.org>; Thu, 29 Dec 2016 16:39:40 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9047734930F; Fri, 30 Dec 2016 00:39:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6CF6216004F; Fri, 30 Dec 2016 00:39:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5989516006B; Fri, 30 Dec 2016 00:39:37 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lXQyxGEE7on7; Fri, 30 Dec 2016 00:39:37 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B2CE316004F; Fri, 30 Dec 2016 00:39:36 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6B6855E1091C; Fri, 30 Dec 2016 11:39:32 +1100 (EST)
To: "John R Levine" <johnl@taugh.com>
From: Mark Andrews <marka@isc.org>
References: <20161229161837.34614.qmail@ary.lan> <20161229234812.EC4E95E104BC@rock.dv.isc.org> <alpine.OSX.2.11.1612291855380.37956@ary.qy>
Subject: Re: IPv6, was IPv10
In-reply-to: Your message of "29 Dec 2016 18:56:26 -0500." <alpine.OSX.2.11.1612291855380.37956@ary.qy>
Date: Fri, 30 Dec 2016 11:39:32 +1100
Message-Id: <20161230003932.6B6855E1091C@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/iEOPjhp4vLeKghOhb5KRwMmtUCk>
Cc: IETF general list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2016 00:39:41 -0000

In message <alpine.OSX.2.11.1612291855380.37956@ary.qy>qy>, "John R Levine" writes:
> > It sounds like you want a homenet router.
> 
> Possibly, but I'd rather have a v6 network where the addresses hold still.

Well there are routers that do keep internal prefixes stable.  It
isn't that hard to say interface A has 0 in bits 49 to 64 and
interface B is 1 in bits 49 to 64 etc.  This works with almost any
prefix length the ISP gives you by filling in the least significant
bits.  Then as long as you get the same prefix from the ISP all
your addressing is stable even without ULA.

With ULAs you can assign the /64's to each interface.  This doesn't
prevent PA prefixes co-existing with the ULAs.

> > Mind you a lot of this would be a non-issue if hosts used the DNS
> > to its full potential by updating their own addresses in the DNS
> > using SIG(0) signed UPDATE messages when their addresses change.
> 
> That would be swell except the DNS server's address changes, too.

So what.  The DNS server's addresses are in the DNS so UPDATEs still
work.  Normally a router will be a recursive DNS server so it can
advertise its own addresses via DHCP and RA or it will learn recursive
server addresses these ways and re-advertise them on its local
links.

There is NOTHING but inertia stopping the entire DNS being securely
dynamically updated over the DNS.  That includes updating DS, NS
and glue addresses records in parent zones.  The only thing that
needs longer term stability are the root servers.  Even they can
change slowly.

Nameserver can learn when they have new addresses and send out
signed UPDATE messages to update glue records in parent zones.  We
can even redirect these update messages to specialised machines
that just process the update messages.  We even have a SRV prefix
defined to allow a zone operator to do this.  Apple (with DYN I
believe) registered this about a decade ago now.  They did that to
allow CPE's routers to register their public addresses in the DNS
when they were updated via DHCP.  This works equally well for IPv4
or IPv6.

It isn't that hard to figure out the addresses of DNS servers.  We
do that all the time to send out NOTIFY messages.  There is no need
for a slave server to have a hard coded list of addresses to transfer
the zone from.  It is just intertia at this stage.  Adding this
functionality to named has been on my todo list for years now. It's
just not got to the top.  It can use the last signed NOTIFY source
address or lookup the master server's addresses in the the DNS by
name.  TSIG will prevent transfers false masters succeeding.

Mark

> R's,
> John
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org