Re: IPv6, was IPv10

Mark Andrews <> Thu, 29 December 2016 23:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3F5112989D for <>; Thu, 29 Dec 2016 15:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.001
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ERTe3JD3Ign for <>; Thu, 29 Dec 2016 15:48:24 -0800 (PST)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADCB7129890 for <>; Thu, 29 Dec 2016 15:48:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CD813493EF; Thu, 29 Dec 2016 23:48:22 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTPS id 77332160073; Thu, 29 Dec 2016 23:48:22 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E02E16006B; Thu, 29 Dec 2016 23:48:22 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id QND_JQ2-vTDZ; Thu, 29 Dec 2016 23:48:22 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id 02ADF16004F; Thu, 29 Dec 2016 23:48:21 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id EC4E95E104BC; Fri, 30 Dec 2016 10:48:12 +1100 (EST)
To: "John Levine" <>
From: Mark Andrews <>
References: <20161229161837.34614.qmail@ary.lan>
Subject: Re: IPv6, was IPv10
In-reply-to: Your message of "29 Dec 2016 16:18:37 -0000." <20161229161837.34614.qmail@ary.lan>
Date: Fri, 30 Dec 2016 10:48:12 +1100
Message-Id: <>
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Dec 2016 23:48:26 -0000

In message <20161229161837.34614.qmail@ary.lan>an>, "John Levine" writes:
> >>No, we are obviously not ready with [3] yet,
> >
> >I don¹t understand this statement, since thousands of access providers and
> >enterprises are running IPv6.
> There are still all sorts of places that things that are easy and
> painless with IPv4 are much too hard with IPv6.
> Here's an example: in my house I have a network behind a router
> connected to Time-Warner cable.  T-W gives me one IPv4 address so my
> router NATs.  I configured it once to use and it works
> great.  I have a separate server running DHCP and DNS and some other
> local services.  It hands out fixed addresses for devices like
> printers and the backup server, and dynamic ones for devices like
> phones.  The DNS cache (unbound) knows names for all of the fixed
> address devices, and handles queries from devices on the LAN, which
> are all configured by DHCP to use it.  This took about an hour to set
> up.
> T-W apppears to give me a /48 of IPv6 addresses, so every time my
> router reboots it picks a /64 at random out of that /48, and all of
> the IPv6 addresses on my LAN change.  There is probably some way to
> tell the router, a linux based Ubiquiti Edgerouter, to pick the same
> v6 /64 every time, but I can't figure out what it us.  It was hard
> enough to reverse engineer the router config to make SLAAC work at
> all.  Maybe I should use DHCPv6, but I'd have to figure it out on the
> server side, and then see how well all of my devices support it.
> If IPv6 is going to be useful, I also need a v6 DNS cache.  Since the
> global v6 addresses are unstable, I set the cache to answer on link
> local address FE80::2, and set the router announcements to announce
> it.  All set?  Nope.  That's a link-local address so the address is
> actually FE80::2%xxx where xxx is each device's LAN interface, and
> devices do a generally rotten job of appending the interface name to
> the address they get from SLAAC.  I might be able to use ULAs but I
> have no idea how well ULAs actually work and how I would set them up
> on my servers, so my DNS cache is at and will stay there
> for the indefinite future.
> Perhaps there are ways to deal with all of these, but I am a fairly
> sophisticated network operator, and I doubt I am all that much less
> competent than everyone else.  So when people say IPv6 still isn't
> ready for prime time, they're not kidding.
> R's,
> John

It sounds like you want a homenet router.

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.
SIG(0) signs using the private half of a KEY record installed in
the DNS, at the machines name, when the machine was named.  This
would be done using a TSIG signed update (think key name and password)
for the zone.

You then end up with KEY ... AAAA ... AAAA ... A ...

and you configure the nameserver to allow UPDATE messages signed
with to update  This policy can
be specified in named like this.  I would expect that other vendor
can do similar.

key {
	algorithm "hmac-sha256";
	secret "xxxxxxxxxxxxxxxxx";

zone {
	type master;
	file "";
	update-policy {
		grant subdomain KEY;
		grant * self * A AAAA;

Microsoft do something similar using AD and GSS-TSIG instead of
SIG(0).  You use the domain password to perform the initial
registration of the machine after that it updates its own addresses.
This just stores all the keying data in the DNS rather than extenally.

Now it is possible to allow adding of SRV records.

	grant * selfsub * A AAAA SRV;

which allows to " SRV ..." to be added.

This functionality has existed for over a decade now.  This is not
new.  It flows logically from combining RFC 2136, RFC 2845 and RFC

It would be possible to specify a policy which allows for a KEY
record to be added if there is no existing records at a name from
a given address range over TCP.  This would allow for self registration
of devices without having to use a adminstrative key.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: