Re: IPv6, was IPv10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <20161229161837.34614.qmail@xxxxxxx>, "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 192.168.80.0/24 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 192.168.80.2 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

host.example.net KEY ...
host.example.net AAAA ...
host.example.net AAAA ...
host.example.net A ...

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

key example.net.key {
	algorithm "hmac-sha256";
	secret "xxxxxxxxxxxxxxxxx";
};

zone example.net {
	type master;
	file "example.net.db";
	update-policy {
		grant example.net.key subdomain example.net 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 "_foo._bar.host.example.net. 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
2931.

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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@xxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]